Skip to content

Releases and publishing

Release creation (release.yml) and artifact publication (publish.yml). The develop channel is in Continuous integration. Registry and credential rules are on the CI/CD overview.

release.yml

Purpose:

  • start a release manually from main: create the Git tag and the GitHub release for the version in VERSION, then publish the images and the Helm chart

Triggers:

  • workflow_dispatch

Behavior of the prepare job:

  • fails early when the selected ref is not main
  • has no write access and no secrets, because it runs dependency code
  • checks out the commit, then uses ./.github/actions/check-develop-gate with branch: main and stops if CI did not pass for the head commit of main
  • uses ./.github/actions/suite-tests with caching disabled (enable_cache: false) to run make test, and then runs make check-lockstep-version
  • reads the version from VERSION and verifies that the tag does not exist locally or on the remote
  • extracts the release notes with make release-notes (the CHANGELOG.md section ## Version <VERSION>). The job fails if the section is missing or empty
  • gives the version and the release notes to the next jobs as job outputs
  • does not use the uv cache or the Go cache
  • summarizes the CI gate, version checks, tag checks, and release-note preparation

Behavior of the tag-and-release job:

  • runs after prepare and runs no dependency code
  • checks out the commit with the DEPLOY_KEY SSH key and pushes the tag <VERSION> over SSH (without --force). The organisation ruleset does not let GITHUB_TOKEN create tags, and the deploy key is a bypass actor
  • the checkout step has a zizmor: ignore[artipacked] comment. The next step needs the key, the job uploads no artifacts, and the checkout action removes the key at the end of the job
  • creates the GitHub release (title Version <VERSION>) on the existing tag with gh release create --verify-tag --notes-file, through the GitHub API
  • if the release step fails after the tag push, the tag stays. Delete the tag, or create the release manually, before you run the workflow again
  • the workflow-level concurrency group allows only one release run at a time
  • summarizes the tag and GitHub release result without including release notes or secrets

Behavior of the publish job:

  • runs after the prepare and tag-and-release jobs and calls publish.yml with the new tag

Permissions:

  • top-level none
  • prepare job: contents: read and actions: read
  • tag-and-release job: contents: write
  • publish job: contents: read and id-token: write

Secrets and tokens:

  • GITHUB_TOKEN is used by gh release create. The first checkout does not keep a token
  • DEPLOY_KEY is a deploy key with write access that can bypass the tag ruleset. Only the tag-and-release job uses it
  • ECCR_USERNAME and ECCR_PASSWORD go to publish.yml
  • DOCS_BASE_URL and DOCS_TOKEN go to publish.yml for the documentation upload

publish.yml

Purpose:

  • publish release-tagged images and the Helm chart for a release tag

Triggers:

  • workflow_call, from release.yml
  • workflow_dispatch, to publish an existing tag again

Both triggers have the required input tag. The workflow does not start on the release event. A release that GITHUB_TOKEN creates does not start other workflows, and a release created in another way would publish a second time.

Behavior:

  • checks out the tag, without a persisted token
  • fails if the VERSION file in the tag is not the same as the tag
  • uses the same runner (arc-dind-pet-vsphere-prod in pet-privileged-runners) and publishing action as develop.yml
  • runs make release, which validates lockstep versioning and publishes the images and the Helm chart using the root VERSION
  • a concurrency group for each tag stops two publishes of the same tag at the same time
  • the publish-docs job runs after publish on the same runner type. It checks out the tag, sets up uv (no cache), installs a fixed sitesctl build (SITESCTL_VERSION) from the ECMWF repository and verifies its SHA-256 (SITESCTL_SHA256), and runs make publish-docs with DOCS_SOURCE_REF set to the tag
  • all releases upload to one documentation site. The publish-docs concurrency group (without cancellation) allows one upload at a time. If you publish an older tag again, its pages replace the newer pages with the same name
  • the publish job checks first that DOCS_BASE_URL and DOCS_TOKEN are set, so a missing setting fails before the images are built. A failed upload fails the workflow
  • both jobs summarize their release tag, publishing target, and final job status

Permissions:

  • top-level contents: read
  • publish job: contents: read and id-token: write (Vault authentication)
  • publish-docs job: contents: read

Credential inputs:

  • ECCR_USERNAME
  • ECCR_PASSWORD
  • DOCS_BASE_URL: the Sites platform URL. Set it as a repository secret or variable. The secret takes precedence
  • DOCS_TOKEN: a repository secret with a token that has write access to the destination site. The publish job receives it only for the pre-publication presence check; the upload step in publish-docs is the only consumer

The credential action accepts repository secrets. It does not read repository variables. If either value is missing, it uses Vault with GitHub OpenID Connect (OIDC) authentication.