GitLab Runner Helm Chart 1.0
Overview
The helm chart right now is still at a 0.x
release, and since we follow sementic versioning it means that the helm chart is still a beta feature and we should look into releasing a 1.0 to mark the stability of it.
Breaking Changes
Possible features that require breaking changes
- gitlab-org/gitlab-runner#4511 (moved)
- Remove/Rename default value for cache secret which is fixed in !177
Bug fixes that would be simpler with breaking changes
Below is a list of bugs we have that can be easily fixed if can do breaking changes if want to keep backward compatibility the workarounds are less then ideal.
Improvements on the deployment
- Add
release
label as a selector, something like what !181 (merged) is reverting - Do not duplicate name in release_name
values.yml
Problems with Right now the GitLab Runner team already ensures backward compatibility between each release, but it's getting harder every day before of some fundamental stuff on the values.yml
file which what users use to configure the Runner. The biggest drawback of the current structure is that it doesn’t reflect how the config.toml
is build, it re-uses runner
some related names but in a different context (e.g. helper
which is used to… define resource limits for the helper image and is put under runners:
scope…) which confuses even more.
Right now there is no notion of GitLab Runner Manager
and Build Pods
which each of them have different meaning and different configuration for example, this nodeslector and this nodeselector, at a glance they are not very clear which one is for the Runner Manager pod itself and the other for the config.toml
file.
Right now we don't really mention the config.toml
anywhere, we hide that from the user we introduce the definition of build pod
which is the pod that GitLab Runner will create to run a job, but it's not clear that is what we mean here.
Moving the location of the GitLab Helm chart
Right now the helm chart can be found in https://gitlab.com/charts/gitlab-runner which is a different group as https://gitlab.com/gitlab-org and this causes confusion for developers, tooling, and discoverability it leads to issues like https://gitlab.com/charts/gitlab/issues/1382 which can completely be prevented if it's under the gitlab-org
group, this seems to be an easy change to do https://gitlab.com/charts/gitlab/issues/1382#note_184027576
Things we need to discuss
- Release timeline.
- How to actually do the 1.0, right now with the work above it seems like there is a lot of work for 1 milestone release so we need to think of a way on how to split it in in multiple releases.
- When we create 1.0, when will 2.0 come? Should we start following the same major release as GitLab does? Meaning in 13.0 we release 2.0? That would mean the time period between the major release to be less than 1 year.
Other teams involved
~Configure: The configure team uses this helm chart for GitLab Managed Apps where GitLab Runner can be installed using this helm chart. They also have their own set of configuration that we need to be aware of.
~Distribution: The distribution team use this helm chart to provision a GitLab Runner that can be configured and needs to be taken into consideration when we make breaking changes.