<!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> *This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.* <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> ## Overview The [helm chart](https://gitlab.com/charts/gitlab-runner) right now is still at a `0.x` release, and since we follow [sementic versioning](https://semver.org/) 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 - https://gitlab.com/gitlab-org/gitlab-runner/issues/4511 - [Remove/Rename default value for cache secret](https://gitlab.com/gitlab-org/charts/gitlab-runner/merge_requests/166#note_220456936) which is fixed in https://gitlab.com/gitlab-org/charts/gitlab-runner/merge_requests/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. - [Fix the pod label and annotation escaping](https://gitlab.com/charts/gitlab-runner/merge_requests/117) - [Update the spelling of application file](https://gitlab.com/charts/gitlab-runner/merge_requests/122) ### Improvements on the deployment - Add `release` label as a selector, something like what https://gitlab.com/gitlab-org/charts/gitlab-runner/merge_requests/181 is reverting - [Do not duplicate name in release_name](https://gitlab.com/gitlab-org/charts/gitlab-runner/merge_requests/176) ### Problems with `values.yml` 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`](https://gitlab.com/charts/gitlab-runner/blob/753034d0f0247eca50e10963c45cb91abef4e71d/values.yaml) 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`](https://gitlab.com/charts/gitlab-runner/blob/753034d0f0247eca50e10963c45cb91abef4e71d/values.yaml#L86) 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](https://gitlab.com/charts/gitlab-runner/blob/753034d0f0247eca50e10963c45cb91abef4e71d/values.yaml#L268) and [this nodeselector](https://gitlab.com/charts/gitlab-runner/blob/753034d0f0247eca50e10963c45cb91abef4e71d/values.yaml#L219), 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](https://docs.gitlab.com/ee/user/clusters/applications.html) where GitLab Runner can be installed using this helm chart. They also have their [own set of configuration](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/vendor/runner/values.yaml) that we need to be aware of. ~Distribution: The distribution team use this helm chart to provision a GitLab Runner that [can be configured](https://gitlab.com/charts/gitlab/blob/c5aa83efbf7cd2ae16456f40f85f4550338c4aab/templates/_runner.tpl) and needs to be taken into consideration when we make breaking changes.