<p><strong>Management Summary</strong></p>

<p>Set the <code>pull_policy</code> to <code>"never"</code> in the <code>[runners.docker]</code> section by calling:</p>

<pre><code>docker exec -it gitlab-runner \
  vi /etc/gitlab-runner/config.toml
</code></pre>

<p><strong>Detailed Description</strong></p>

<p>It seemed the problem was a confusion with images and mounted volumes.</p>

<p>The documentation says to configure runners in:</p>

<pre><code>/etc/gitlab-runner/config.toml
</code></pre>

<p>Which I did, but on the host machine.
When running <code>gitlab-runner</code> in a docker container, it mounts a volume:</p>

<pre><code>... -v /srv/gitlab-runner/config:/etc/gitlab-runner ...
</code></pre>

<p>This means, that the configuration file in <code>/etc/...</code> in the container is mounted to <code>/srv/...</code> on the host machine.</p>

<p>In this file the <code>pull_policy</code> was not set, which defaults to <code>always</code>, what ultimately caused my problem in the first place.</p>

CC BY-SA 4.0
2017-07-10T07:36:24.760Z
2020-03-03T11:29:18.033Z
2020-03-03T11:29:18.033Z
tgr
<p>I have a gitlab instance running in a docker container. Now I would like to setup gitlab-runner on the same host. Both are running:</p>

<pre><code>docker container ls
CONTAINER ID        IMAGE                         COMMAND                  CREATED              STATUS                 PORTS                                                            NAMES
279473dceb2f        gitlab/gitlab-runner:alpine   "/usr/bin/dumb-ini..."   About a minute ago   Up About a minute                                                                       gitlab-runner
6d7af0d6b946        gitlab/gitlab-ce:latest       "/assets/wrapper"        2 hours ago          Up 2 hours (healthy)   0.0.0.0:80-&gt;80/tcp, 0.0.0.0:443-&gt;443/tcp, 0.0.0.0:8022-&gt;22/tcp   gitlab
</code></pre>

<p>I registered a docker image as a shared runner:</p>

<pre><code>concurrent = 1
check_interval = 0

[[runners]]
  name = "default shared maven runner"
  url = "http://url-of-my-gitlab.instance"
  token = "valid token"
  executor = "docker"
  [runners.docker]
    pull_policy = "never"
    tls_verify = false
    image = "maven-java-8:latest"
    privileged = false
    disable_cache = false
    volumes = ["/cache"]
    shm_size = 0
  [runners.cache]
</code></pre>

<p>The registered image <code>maven-java-8</code> is a custom image with the correct settings.xml and it is listed in <code>docker images</code>.</p>

<p>But still the pipeline fails with:</p>

<pre><code>Running with gitlab-ci-multi-runner 9.3.0 (3df822b)
  on Maven Test (5b2573e4)
Using Docker executor with image maven-java-8 ...
Using docker image  sha256:c266311d78b33f89f6eecce00f19a0428e37ba6af6734c8fced32fa11e4bd4ba for predefined container...
Pulling docker image maven-java-8 ...
ERROR: Job failed: Error response from daemon: repository maven-java-8 not found: does not exist or no pull access
</code></pre>

<p>Which I interpret as it is trying to use the local images inside of the gitlab-runner container.</p>

<p>The GitLab version is gitlab-ce 9.2.7 and the runner version is v9.3.0.</p>

<p>The content of my .gitlab-cy.yml is:</p>

<pre><code>test:
  script:
    - mvn clean test
</code></pre>

<p>What am I missing?</p>

<docker><continuous-integration><gitlab>
How to configure gitlab-runner to run in the same docker host as gitlab?
tgr
# How to configure gitlab-runner to run in the same docker host as gitlab?

(Asked by: username_0 on 2017-07-07)

I have a gitlab instance running in a docker container. Now I would like to setup gitlab-runner on the same host. Both are running:
docker container ls
CONTAINER ID        IMAGE                         COMMAND                  CREATED              STATUS                 PORTS                                                            NAMES
279473dceb2f        gitlab/gitlab-runner:alpine   "/usr/bin/dumb-ini..."   About a minute ago   Up About a minute                                                                       gitlab-runner
6d7af0d6b946        gitlab/gitlab-ce:latest       "/assets/wrapper"        2 hours ago          Up 2 hours (healthy)   0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp, 0.0.0.0:8022->22/tcp   gitlab

I registered a docker image as a shared runner:
concurrent = 1
check_interval = 0

[[runners]]
  name = "default shared maven runner"
  url = "http://url-of-my-gitlab.instance"
  token = "valid token"
  executor = "docker"
  [runners.docker]
    pull_policy = "never"
    tls_verify = false
    image = "maven-java-8:latest"
    privileged = false
    disable_cache = false
    volumes = ["/cache"]
    shm_size = 0
  [runners.cache]

The registered image maven-java-8 is a custom image with the correct settings.xml and it is listed in docker images.
But still the pipeline fails with:
Running with gitlab-ci-multi-runner 9.3.0 (3df822b)
  on Maven Test (5b2573e4)
Using Docker executor with image maven-java-8 ...
Using docker image  sha256:c266311d78b33f89f6eecce00f19a0428e37ba6af6734c8fced32fa11e4bd4ba for predefined container...
Pulling docker image maven-java-8 ...
ERROR: Job failed: Error response from daemon: repository maven-java-8 not found: does not exist or no pull access

Which I interpret as it is trying to use the local images inside of the gitlab-runner container.
The GitLab version is gitlab-ce 9.2.7 and the runner version is v9.3.0.
The content of my .gitlab-cy.yml is:
test:
  script:
    - mvn clean test

What am I missing?

**Tags:** docker, continuous-integration, gitlab


---

## 1 answers

### Answer by username_0 on 2017-07-10. Score: 6 | Accepted answer

Management Summary
Set the pull_policy to "never" in the [runners.docker] section by calling:
docker exec -it gitlab-runner \
  vi /etc/gitlab-runner/config.toml

Detailed Description
It seemed the problem was a confusion with images and mounted volumes.
The documentation says to configure runners in:
/etc/gitlab-runner/config.toml

Which I did, but on the host machine.
When running gitlab-runner in a docker container, it mounts a volume:
... -v /srv/gitlab-runner/config:/etc/gitlab-runner ...

This means, that the configuration file in /etc/... in the container is mounted to /srv/... on the host machine.
In this file the pull_policy was not set, which defaults to always, what ultimately caused my problem in the first place.


---

