Releasing K8up

This repository contains code releases as well as Helm chart releases. They are using separate versioning scheme, each using SemVer.

Any Pull Request must clearly isolate code changes from Helm chart changes. Otherwise, there could be issues with the release automation and the generated changelog.

Changes to the repository boilerplate, CI/CD or similar shall be considered as normal code change.

The PR template reminds you how to separate and label PRs.

Operator Release

The release process is automated all the way through. Releasing a new version of the operator requires pushing a new Git tag, following the SemVer schema with a v prefix. Optionally, for prereleases they may contain a ascending release candidate suffix with -rc#.

Example 1. Possible Operator Git tags

  • v0.1.2

  • v1.4.0

  • v2.0.0-rc1

  • v2.0.0-rc2

  • v2.0.0

The release notes will be automatically created and is based on merged PRs. PRs that affect Helm charts are excluded. The following labels must exist on a PR to be included in the release notes:

  • area:operator

  • one of [bug, enhancement, documentation, change, breaking, dependency]

Once the operator is released, consider creating another PR that updates the Helm chart with the newly-created release tag.

The following is the result:

  • A GitHub release with release notes based on the merged pull requests, only displaying changes between operator releases. The release contains the binary as well as the CRDs in YAML.

  • A build of the Docker image, which is pushed to GitHub Container Registry and Quay.io.

  • A new version selector in the documentation if the version is minor or major.

This process mostly relies on GoReleaser.

Helm Chart Release

Releasing a new version of a Helm chart requires pushing a new Git tag, following the SemVer schema with a chart name prefix, for example k8up-3.2.1. It’s recommended to create a PR for each Helm chart change separately. After merging a PR for a Helm chart it’s not required to immediately release it.

The PR should only contain changes in the charts/ directory. Each affected chart must set the version in Chart.yaml to the same as the Git tag, following SemVer. The chart README must be generated using make chart-docs to ensure that the README is generated using special comments in values.yaml.

Example 2. Possible Helm chart Git tags

  • k8up-2.2.3

The release notes will be automatically created and is based on merged PRs. PRs that affect code changes are excluded. The following labels must exist on a PR to be included in the release notes:

  • area:chart

  • chart:k8up

  • one of [bug, enhancement, documentation, change, breaking, dependency]

If the Helm chart updates the image tag for the operator, it’s recommended to set a title like Update image tag to vx.y.z or similar and set the dependency label.

Prereleases for Helm charts are currently not supported.

The result is a GitHub release with release notes based on the merged pull requests, only displaying changes between chart releases. The release contains the chart archive as well as the CRDs in YAML.