Releases of comit-rs components are mostly automated based on the GitFlow branching model.
For the release workflows to work, the repository needs to expose the following "secrets":
BOTTY_GITHUB_TOKEN
: A personal access token of our GitHub bot user COMIT Botty McBotfaceDOCKER_REGISTRY_USERNAME
: The username to use for logging into DockerHubDOCKER_REGISTRY_PASSWORD
: The password of said user
The reason we are using a dedicated bot user is because GitHub doesn't allow recursive workflows by default. As a result, the release branch created by GH actions would for example not trigger the CI build.
Trigger this workflow with the version you want to release.
The workflow will create a release branch and tag you in a PR for merging this branch into master
.
Once you are ready to do the release, simply merge the PR.
This will trigger further workflows and eventually:
- Create a GH release
- Build a release binary of cnd for Linux, MacOS and Windows and attach them to the release
- Build a docker image and publish it on DockerHub
In total, the automation is composed of three GitHub action workflows:
The following diagram illustrates how these work together:
We split the release into different workflows for several reasons.
- Building and attaching the binary needs to happen for several platforms whereas the actual release (and tag) only needs to be created once.
- It allows for multiple entry-points into the release process: Building binaries is triggered by a "release" event, which could in theory be created manually and doesn't necessarily have to be created through the release automation.
Trigger this workflow with the version you want to release.
Releasing nectar is identical to cnd except that we don't publish a docker image for nectar.
Even though the release workflow is very similar to cnd, we chose to duplicate it and make it specific to nectar. While it would probably be possible to make one workflow that can handle both, it would make it more complicated. Given that it is really hard to test these workflows (basically have to be tested manually), we choose to avoid as much complexity as possible.