Skip to content
This repository has been archived by the owner on Mar 23, 2021. It is now read-only.

Latest commit

 

History

History
51 lines (33 loc) · 2.97 KB

RELEASING.md

File metadata and controls

51 lines (33 loc) · 2.97 KB
Raw

Releasing

Releases of comit-rs components are mostly automated based on the GitFlow branching model.

Necessary GH action secrets

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 McBotface
  • DOCKER_REGISTRY_USERNAME: The username to use for logging into DockerHub
  • DOCKER_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.

Releasing cnd

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

Technical documentation

In total, the automation is composed of three GitHub action workflows:

  1. Draft new release
  2. Create GitHub release
  3. Build the release binary and attach it to the GH release

The following diagram illustrates how these work together: Cnd release sequence diagram

We split the release into different workflows for several reasons.

  1. Building and attaching the binary needs to happen for several platforms whereas the actual release (and tag) only needs to be created once.
  2. 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.

Releasing nectar

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.