<p>I'm have a Gitlab cloud connected to a k8s cluster running on Google (GKE).
The cluster was created via Gitlab cloud.</p>

<p>I want to customise the <code>config.toml</code> because I want to <em>fix</em> the cache on k8s as suggested in <a href="https://gitlab.com/gitlab-org/gitlab-runner/issues/1906" rel="noreferrer">this issue</a>.</p>

<p>I found the <code>config.toml</code> configuration in the <code>runner-gitlab-runner</code> ConfigMap.
I updated the ConfigMap to contain this <code>config.toml</code> setup:</p>

<pre><code>  config.toml: |
    concurrent = 4
    check_interval = 3
    log_level = "info"
    listen_address = '[::]:9252'
    [[runners]]
      executor = "kubernetes"
      cache_dir = "/tmp/gitlab/cache"
      [runners.kubernetes]
        memory_limit = "1Gi"
        [runners.kubernetes.node_selector]
          gitlab = "true"
        [[runners.kubernetes.volumes.host_path]]
          name = "gitlab-cache"
          mount_path = "/tmp/gitlab/cache"
          host_path = "/home/core/data/gitlab-runner/data"
</code></pre>

<p>To apply the changes I deleted the <code>runner-gitlab-runner-xxxx-xxx</code> pod so a new one gets created with the updated <code>config.toml</code>.</p>

<p>However, when I look into the new pod, the <code>/home/gitlab-runner/.gitlab-runner/config.toml</code> now contains 2 <code>[[runners]]</code> sections:</p>

<pre><code>listen_address = "[::]:9252"
concurrent = 4
check_interval = 3
log_level = "info"

[session_server]
  session_timeout = 1800

[[runners]]
  name = ""
  url = ""
  token = ""
  executor = "kubernetes"
  cache_dir = "/tmp/gitlab/cache"
  [runners.kubernetes]
    host = ""
    bearer_token_overwrite_allowed = false
    image = ""
    namespace = ""
    namespace_overwrite_allowed = ""
    privileged = false
    memory_limit = "1Gi"
    service_account_overwrite_allowed = ""
    pod_annotations_overwrite_allowed = ""
    [runners.kubernetes.node_selector]
      gitlab = "true"
    [runners.kubernetes.volumes]

      [[runners.kubernetes.volumes.host_path]]
        name = "gitlab-cache"
        mount_path = "/tmp/gitlab/cache"
        host_path = "/home/core/data/gitlab-runner/data"

[[runners]]
  name = "runner-gitlab-runner-xxx-xxx"
  url = "https://gitlab.com/"
  token = "&lt;my-token&gt;"
  executor = "kubernetes"
  [runners.cache]
    [runners.cache.s3]
    [runners.cache.gcs]
  [runners.kubernetes]
    host = ""
    bearer_token_overwrite_allowed = false
    image = "ubuntu:16.04"
    namespace = "gitlab-managed-apps"
    namespace_overwrite_allowed = ""
    privileged = true
    service_account_overwrite_allowed = ""
    pod_annotations_overwrite_allowed = ""
    [runners.kubernetes.volumes]
</code></pre>

<p>The file <code>/scripts/config.toml</code> is the configuration as I created it in the ConfigMap.
So I suspect the <code>/home/gitlab-runner/.gitlab-runner/config.toml</code> is somehow updated when registering the Gitlab-Runner with the Gitlab cloud.</p>

<p>If if changing the <code>config.toml</code> via the ConfigMap does not work, how should I then change the configuration? I cannot find anything about this in Gitlab or Gitlab documentation.</p>

Joost den Boer
<p>Inside the mapping you can try to append the volume and the extra configuration parameters:</p>
<pre><code># Add docker volumes
cat &gt;&gt; /home/gitlab-runner/.gitlab-runner/config.toml &lt;&lt; EOF

      [[runners.kubernetes.volumes.host_path]]
        name = &quot;var-run-docker-sock&quot;
        mount_path = &quot;/var/run/docker.sock&quot;
EOF
</code></pre>
<p>I did the runner deployment using a helm chart; I guess you did the same, in the following link you will find more information about the approach I mention: <a href="https://gitlab.com/gitlab-org/gitlab-runner/issues/2578" rel="nofollow noreferrer">https://gitlab.com/gitlab-org/gitlab-runner/issues/2578</a></p>
<p>If after appending the config your pod is not able to start, check the logs, I did test the appending approach and had some errors like &quot;Directory not Found,&quot; and it was because I was appending in the wrong path, but after fixing those issues, the runner works fine.</p>
