GitLab Runner Helm Chart 1.0
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.
Possible features that require breaking changes
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.
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
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.