Hi,
I’m co-maintainer of a gitlab-runner role, which is managing gitlab-runners on the client side. For server side, there is an existing community module.
The only drawback of the gitlab role is, that it has to manage a complex toml file: /etc/gitlab-runner/config.toml
. The content of this toml looks like this:
concurrent = 1
check_interval = 0
connection_max_age = "15m0s"
shutdown_timeout = 0
[session_server]
session_timeout = 1800
[[runners]]
name = ""
output_limit = 4096
url = ""
id = 1
token = ""
token_obtained_at = 2025-02-25T22:39:22Z
token_expires_at = 0001-01-01T00:00:00Z
executor = "shell"
[runners.cache]
MaxUploadedArchiveSize = 0
[runners.cache.s3]
[runners.cache.gcs]
[runners.cache.azure]
[[runners]]
name = ""
output_limit = 4096
url = ""
id = 2
token = ""
token_obtained_at = 2025-03-12T09:28:50Z
token_expires_at = 0001-01-01T00:00:00Z
executor = "docker"
[runners.cache]
MaxUploadedArchiveSize = 0
[runners.cache.s3]
[runners.cache.gcs]
[runners.cache.azure]
[runners.docker]
tls_verify = false
image = "ubuntu:24.04"
privileged = false
disable_entrypoint_overwrite = false
oom_kill_disable = false
disable_cache = false
volumes = []
shm_size = 0
network_mtu = 0
The file is quite complex and the original author of the role did a really awesome job splitting this file up in chunks, modify it then and put it back together.
Unfortunetely, the file itself is not 100% managed by ansible, but when the gitlab-registation is done, some parts of the file are modified by gitlab itslef (e.g. ids, tokens, …). That means that we cannot simply use a template for creating this file, but need to read in the existing file and only touch the parts which are allowed to be touched on client side.
Because of splitting up the file in ansible, the runs are very slow and are not done in parallel but host by host (ansible related topic).
Now the question for me would be, if it is worth to create an own module to manage this config.toml.
What do you think?