Release 2.11
Release checklist
Pre-release chores
Update our custom charts
Pull in upstream changes to:
If necessary, do a release of the following charts. Don't forget to change the version used in Stackspin (or wait for renovatebot to do that automatically).
-
dashboard (see also dashboard#10) -
nextcloud (see also nextcloud#1012) [ ] wordpress-
hedgedoc [ ] local-path-provisioner
Release candidate
-
Create a new branch, release-candidate/v2.11
, from main:git checkout main git pull git checkout -b release-candidate/v2.11
For all releases
-
Update the version number in the VERSION
file - Update CHANGELOG.md
-
Include all merged MR since last release, i.e. using lab: lab mr list -s merged -a | \ awk '{first = $1; $1=""; print "*" $0, "(" first ")"}'
-
Include app charts and versions table. You can use tablemark-cli, or an online tool: helm ls -A -o json | jq 'map({name, chart, app_version})' | \ jq 'map(.chart |= split("-")[-1])' > /tmp/versions.json
Now look for image tag overrides and fix those app versions in the table:
find ./flux2 -name '*.yaml' | xargs grep -A4 '^ *image:'
Then produce the final table:
tablemark /tmp/versions.json
-
Include Known issues
-
-
Update app versions in flux2/core/base/dashboard/dashboard-apps-configmap.yaml
. -
Decide where to link to from the dashboard "release notes" link. Could be the release blog post, other release notes page, or as fallback the CHANGELOG.md entry for this version. -
Update flux2/cluster/base/stackspin-static-info.yaml
to reflect the new version and the release notes URL. -
Commit, push to release-candidate/v2.11
. -
Create MR to merge release-candidate/v2.11
intopre-release/v2
Automatic pre-release upgrade testing
We have a special upgrade pipeline to test upgrading from the previous release
to this new (candidate) release. This pipeline runs when the target branch of a
MR matches pre-release/*
. In principle you could make a MR to merge main
into pre-release/v2
, but that has the unfortunate side-effect that the
pipeline will restart whenever the source branch changes, which happens all the
time because of renovatebot automerging minor updates and colleagues that work
too hard. Therefore:
-
Make sure that the resulting upgrade-test pipeline is successful -
Wait until MR gets reviewed and merged -
Before merging, notify #general on stackspin.net
that we're about to release, and thatstackspin.net
itself can experience short downtime while the upgrade is in progress. -
The CI machine created by the upgrade-test pipeline doesn't get destroyed automatically, so please remove it yourself.
stackspin.net
Check automatic upgrade on Now that the new code has been merged to pre-release/v2
, it will be picked
up by the stackspin.net
cluster which is set to follow that branch. Even
though the upgrade pipeline already tested the upgrade process, it's still good
to check if the upgrade goes well there:
-
do a flux reconcile source git stackspin
so you don't have to wait until flux decides it's time to reconcile; -
watch flux get kustomization
to see components being upgraded. If necessary check the status usingkubectl describe hr ...
and debug.
Release branch
-
Merge the just-updated pre-release/v2
into the release branchv2
.
Push a signed tag
-
Create and push signed tag ( git tag -s 2.11 -m 'Release 2.11'; git push --tags
)
Post-release chores
-
Announce the release in the public Stackspin matrix room. -
Notify Greenhost sysops that an upgrade to their cluster will happen overnight. -
Update the "stable" CI docker image (used as base for the upgrade pipeline): tag="open.greenhost.net:4567/stackspin/stackspin/stackspin-ci:v2"
docker build -t $tag .
docker push $tag
-
Merge the release branch back into main
. This is necessary to propagate the changes to CHANGELOG etc. -
After demo.stackspin.net
is upgraded, create a new backup for the new version that will be used for the nightly reset. Seecli.stackspin.net
, directory/srv/stackspin/clusters/demo.stackspin.net/custom-scripts
. -
Update the version of the stackspin repo on cli.stackspin.net
:-
git pull
in/srv/stackspin
to get the latest version of the release branch. - Update python requirements:
pip install -r requirements.txt
. Note that we apparently do not use a virtualenv oncli.stackspin.net
.
-
-
Close released milestone and set start date for the new milestone.
Celebration
-
Celebrate 🥂 !!