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...