Publishing a stable release¶
This section describes how to take a branch marked as a stable channel and upload its artifacts to our S3 bucket for distribution. For prior steps before a branch is marked stable, see Stable release process.
Release tooling¶
Ferrocene is developed using a custom tool, publish-release, which is
responsible for all of the release steps. The tool is written in Rust and
developed in the ferrocene/publish-release repository, and it’s executed on
GitHub Actions in the ferrocene/ferrocene repository.
When GitHub Actions invokes the release tool, the calculate-release-job-matrix.py script is used to determine which commit(s) to instruct the release process to release. The script does little when starting a manual release, but it’s fully responsible for determining which scheduled releases to run.
Publishing a manual release¶
Our release tooling also allows to manually start the release process. This can
be useful to start releases that are not on a schedule, to restart a scheduled
release that failed, or for testing (in the dev environment). Only starting
the release is manual, meaning all the rest of steps are fully automated.
To manually start a release, go to the release workflow page and click the “Run workflow” button. You need to input the git reference you want to release (it can be a branch name, a short commit hash, or a full commit hash), and the environment to release in.
Note
The git reference needs to be a merge commit authored by bors.
This is because the Release workflow does not actually build anything, but just copies the release artifacts to the appropriate storage location.
It’s also possible to override some of the startup checks the release process
performs, and to treat the git reference as verbatim instead of trying to
resolve it. The latter option is useful if you need to release a commit which
is not present in the ferrocene/ferrocene repository.
Once you click the green “Run workflow” button, a new job will be queued.
If the release targets the prod environment, an approval from a release manager will be required. The release manager will need to approve the release in the GitHub UI before the release can proceed. Once it’s done, the release process will start automatically.
If there is a service outage preventing you from manually starting a release, follow the instructions in Releasing during outages.