Regression since 0.42.1 - `runners.namespace` changed behavior and is broken in its new behavior
Description of regression
In !343 (merged) the metadata.namespace
became explicitily specified in several resources, but not for the ServiceAccount resource when using the deprecated runners.namespace
configuration.
This was observed using the gitlab
helm chart, bumping from version 6.1.3 to 6.2.0 (and 6.2.1). I concluded that my gitlab-runner deployment had been relocated to the specified namespace, but not the ServiceAccount it needs. I observed that the Deployment resource had 0/1 available pods, and the replica set it created reported the same, and I found no Pods. kubectl describe
on the ReplicaSet reported an Event that it had failed to create the pod as the ServiceAccount was not found
Note that in !343 (merged), the motivation for the chance was:
I noticed that some resources for the GitLab Rubber (the deployment, secret, and configmap) will be installed to the
default
namespace even when specifying the Helm namespace.
To me, this is the expected behavior, as this comment documented runners.namespace
configuration.
Namespace to run Kubernetes jobs in
To me, this means that when the gitlab-runner deployment gets a CI job to start, it will start in that namespace - not that the entire gitlab-runner deployment as well will live in that namespace.
Solution
I suggest reverting !343 (merged). The previous behavior was the documented behavior and worked in its deprecated state.
Workaround
To stop using the runners.namespace
configuration and instead configure the runners.config
with namespace
like below.
runners:
config: |
[[runners]]
[runners.kubernetes]
namespace = "gitlab-runner"
# more stuff here...