OpenShift Operator or Kubernetes Executor: concurrent property of config.toml defined in config map not used
gitlab-org/gitlab-runner#26898 (closed)
I am cross posting this here for a bit more direct visibility of the issue.
Summary
concurrent property of the config.toml specified in the runner's config map is not being applied.
Steps to reproduce
Create a runner using the OpenShift operator. Try to run two jobs simultaneously
What is the current bug behavior?
Only one job will run at a time, yet the config map specified config.toml specifies concurrent as 10.
The log shows that configuration is loaded from /.gitlab-runner/config.toml
Registration attempt 1 of 30
Runtime platform [0;m arch[0;m=amd64 os[0;m=linux pid[0;m=12 revision[0;m=4c96e5ad version[0;m=12.9.0
[0;33mWARNING: Running in user-mode. [0;m
[0;33mWARNING: The user-mode requires you to manually start builds processing:[0;m
[0;33mWARNING: $ gitlab-runner run [0;m
[0;33mWARNING: Use sudo for system-mode: [0;m
[0;33mWARNING: $ sudo gitlab-runner... [0;m
[0;m
Registering runner... succeeded [0;m runner[0;m=VERzrNGt
Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded![0;m
Runtime platform [0;m arch[0;m=amd64 os[0;m=linux pid[0;m=1 revision[0;m=4c96e5ad version[0;m=12.9.0
Starting multi-runner from /.gitlab-runner/config.toml...[0;m builds[0;m=0
[0;33mWARNING: Running in user-mode. [0;m
[0;33mWARNING: Use sudo for system-mode: [0;m
[0;33mWARNING: $ sudo gitlab-runner... [0;m
[0;m
Configuration loaded [0;m builds[0;m=0
Metrics server listening [0;m address[0;m=0.0.0.0:9252 builds[0;m=0
[session_server].listen_address not defined, session endpoints disabled[0;m builds[0;m=0
What is the expected correct behavior?
The concurrent value specified in the config map config.toml should be applied and I should see concurrent job execution (multiple concurrent pods).
Possible fixes
The only workaround I have is to edit /.gitlab-runner/config.toml, which is the file reported by gitlab-runner list
to be where configuration is coming from. However this will not persist through termination of the executor's pod.
Due to the small size of the config.toml specified in config map, it would seem like the desired behavior is to apply .config.toml settings in a hierachical override manner where
/var/tmp/gitlab-runner/.gitlab-runner/config.toml overrides settings from /.gitlab-runner/config.toml but this does not appear to be happening.