The release process needs to do these things:
fluxctlbinaries to the GitHub release
Much of this is automated, but it needs a human to turn the wheel.
The Flux daemon and the Helm operator have separate releases, and use different branches and tags. Flux daemon releases use just a semver version, like
1.8.1, and the Helm operator uses the prefix “helm”, e.g.,
Each minor version has its own “release series” branch, from which patch releases will be put together, called e.g.,
release/1.8.x, or for the Helm operator,
The CircleCI script runs builds for tags, which push Docker images and upload binaries. This is triggered by creating a release in GitHub, which will create the tag.
GITHUB_TOKENwhich is a personal access token. (This is almost certainly already set up, but mentioned here in case it needs to be reinstated.)
Preparing the release PR
If the release is a new minor version, create a “release series” branch and push it to GitHub.
Depending on what is to be included in the release, you may need to pick a point from which branch that is not HEAD of master. But usually, it will be HEAD of master.
From the release series branch, create another branch for the particular release. This will be what you submit as a PR.
git checkout release/1.8.x git pull origin git checkout -b release/1.8.1
Put the commits you want in the release, into your branch
If you just created a new release series branch, i.e., this is a
x.y.0 patch release, you may already have what you need, because you’ve just branched from master.
If this is not the first release on this branch, you will need to either merge master, or cherry-pick commits from master, to get the things you want in the release.
Put an entry into the changelog
For the Flux daemon, it’s
CHANGELOG.md; for the Helm operator, it’s
CHANGELOG-helmop.md. Follow the format established, and commit your
If you cherry-picked commits, remember to only mention those changes.
To compile a list of people (GitHub usernames) to thank, you can use a script (if you have access to weaveworks/dx) or peruse the commits/PRs merged/issues since the last release. There’s no exact way to do it. Be generous.
Post the branch as a PR to the release series
Push the patch release branch -- e.g.,
release/1.8.1 -- to GitHub, and create a PR from it.
Note: You will need to change the branch the PR targets, from
masterto the release series, e.g.,
release/1.8.x, while creating the PR.
Get the PR reviewed, and merge it.
Creating the release
Use a tag name as explained above; semver for the Flux daemon,
helm- then the semver for the Helm operator.
Copy and paste the changelog entry. You may need to remove newlines that have been inserted by your editor, so that it wraps nicely.
Publishing the release will create the tag, and that will trigger CI to build images and binaries.
After publishing the release
Put an entry in the checkpoint database
Add a row to the checkpoint database (or ask someone at Weaveworks to do so). This is so that the up-to-date check will report the latest available version correctly.
Merge the release series branch back into master, so it has the changelog entry.
You can do this by creating a new PR in GitHub -- you don’t need to create any new branches, since you want to merge a branch that already exists.
Consider updating the deploy manifest examples and the Helm chart.
You can do these as additional PRs. Read on, for how to publish a new Helm chart version.
appVersionwith the new Flux version in
image.tagwith the new Flux version in
git tag chart-0.2.2and push it upstream
gh-pagesbranch and run
./bin/update-chart.sh chart-0.2.2, this will generate a new chart release package
update-chart.shand push those changes to