Draft: feat: support multiple runners via runners.configs list
What does this MR do?
Adds a runners.configs list value as an alternative to runners.config, enabling multiple [[runners]] blocks to be registered from a single chart installation.
How it works
-
runners.configsis a list of objects, each with aconfigkey (the TOML template string, evaluated viatpllikerunners.config) plus optional per-runner overrides - The ConfigMap renders a separate
config.template-{i}.tomlper entry - The
register-the-runnerscript callsgitlab-runner registeronce per entry via a shareddo_registerhelper function - Per-runner flag overrides (
name,maximumTimeout,runUntagged,protected) fall back to the top-levelrunners.*values when not set on the entry; an explicitfalseon a per-runner boolean wins over a top-leveltrue -
runners.config(single string) continues to work exactly as before — no breaking change
Example
runners:
configs:
- config: |
[[runners]]
[runners.kubernetes]
namespace = "{{ default .Release.Namespace .Values.runners.jobNamespace }}"
image = "alpine"
name: "alpine-runner"
runUntagged: true
- config: |
[[runners]]
[runners.kubernetes]
namespace = "{{ default .Release.Namespace .Values.runners.jobNamespace }}"
image = "ubuntu"
name: "ubuntu-runner"
protected: true
Why was this MR needed?
The chart previously only supported registering a single runner per installation. Users who needed multiple runners with different configurations (e.g. different images, tags, or executor settings) had to deploy multiple chart releases.
What's the best way to test this MR?
-
helm unittest -f 'tests/*.yaml' .— 14 new unit tests cover the feature; all 64 tests pass - Deploy with a
runners.configslist and verify multiple runners appear in the GitLab UI after pod startup - Deploy with the existing
runners.configand verify no behavior change (backward compat)
What are the relevant issue numbers?
N/A