Initiate GitLab Runner Helm Chart releasing process
Since as a team we now own the GitLab Runner Helm Chart and we've already started integrating Runner's release with Chart's release process, I think it's a time to start thinking on initiating a proper release process for the helm chart, or maybe just making it a part (but fully) of Runner's release.
What we should think about:
-
Version bump in each MR. Currently a new chart is "released" each time when a new MR is merged. This requires a bump of version number in
Chart.yaml
in each MR, which is a frequent source of merge conflicts. It also means that neither we or our community have a time to do astaging
like tests of added changes, before we consider it astable
. After merging it's almost immediately available for all users, and in case of problems, it needs to be immediately reverted.It needs to be checked if merging changes to
master
(which is the source for our helm chart repository) without bumping version number is OK. And then decide what to do, to start releasing a new version each month, at 22nd, after updating the version of used GitLab Runner image. -
Git tags. However it's not needed for the helm chart repository, I think we should start adding git tags for each released version. This will give use at least a possibility to do simple diffs (like
git diff v0.1.10..0.1.15
), which is very hard now, since one need to scan commits searching which commit created which version of the chart. Reducing the number of "released" versions to few per month in that case is a must-have. -
Version numbering. The only requirement that Helm adds is to use SemVer 2 pattern. Currently our chart is versioned fully separately from GitLab Runner version that is used. So while I've just created a MR that updates used Runner to
11.5.0
, the version of the Chart was bumped to0.1.38
.Maybe, it would be worth to align versions, so the version of a chart would be now
11.5.0-0
, where11.5.0
represents the version of Runner, while-0
gives a way to version chart updates with the same used version of the Runner. If we would like to release an RC, then it could be something like11.5.0-0-rc1
.Update 2019-01-03
After a discussion in charts/gitlab-runner!72 we've decided, that we will not use a
X.Y.Z-N
pattern. Such pattern by Helm is treated as a development versions and by default they are not available - a--devel
flag is needed to use them. This means that by default users couldn't update Runner without using--develop
flag.For now we will stay with a separated versioning for the Helm Chart. Instead we will start using
appVersion
value from theChart.yaml
to mark which version of Runner is used by specific version of Runner's Helm Chart. -
Start using
X-Y-stable
branch pattern to make sure that changes merged into the chart repository after 7th are moved to a next release and they need to be explicitly cherry-picked to theX-Y-stable
branch if needed (so do exactly the same as we do now for GitLab Runner etc.). -
Start releasing RCs of the chart, and do this at the same time when Runner's RC is released. So in fact we would tag Runner's RC1, and then we need to extend our checklist to update the chart to use Runner X.Y.0-RC1 and release an RC1 version of the chart. And the same for all further RCs if needed.
-
Start managing a CHANGELOG file? If we would re-use the same mechanism that we have for GitLab Runner, it would be quite easy to maintain (we create CHANGELOG entries basing on MR titles).
-
Start adding information about new release to the blog post (there is already an entry for the GitLab Helm Chart)?
-
Anything else?
I recently started reviewing some of the MRs, and I don't feel the same comfortable with merges as for example I feel for Runner. When reviewing Runner I know, that if I'll miss some bug during a review, it will be most probably discovered after we'll release RC1, and there will be a time to fix it before releasing a new stable version (which doesn't mean I don't make a careful reviews). For the GitLab Runner Helm Chart project I don't have such comfort, since anything merged to master
, becomes a stable version.
Since we own the chart, we should consider making it releases more structured than hey, jump in, merge my 250+ lines change and make it a new stable version right now
-
Get proper access levels to https://gitlab.com/charts/gitlab-runner and https://gitlab.com/charts/charts.gitlab.io projects for people that will be releasing Runner + Helm Chart -
Update the CI pipeline, so only tags will trigger downstream jobs in https://gitlab.com/charts/charts.gitlab.io: charts/gitlab-runner!72, charts/charts.gitlab.io!134 (merged) -
Update Helm Chart's project settings (like protected branches and tags, required approvals etc.) with the ones we have in GitLab Runner's project -
Update the way how Runner version is configured in the Helm Chart: charts/gitlab-runner!74 -
Prepare CHANGELOG management in Helm Chart project: charts/gitlab-runner!75 -
Update Release Checklist template to include Helm Chart into the release steps: !1131 (merged)