| `name` | yes, when used with any other option | 9.4 |Full name of the image that should be used. It should contain the Registry part if needed. |
| `entrypoint` | no | 9.4 |Command or script that should be executed as the container's entrypoint. It will be translated to Docker's `--entrypoint` option while creating the container. The syntax is similar to [`Dockerfile`'s `ENTRYPOINT`](https://docs.docker.com/engine/reference/builder/#entrypoint) directive, where each shell token is a separate string in the array. |
| `entrypoint` | no | 9.4 |Command or script that should be executed as the container's entrypoint. It's translated to Docker's `--entrypoint` option while creating the container. The syntax is similar to [`Dockerfile`'s `ENTRYPOINT`](https://docs.docker.com/engine/reference/builder/#entrypoint) directive, where each shell token is a separate string in the array. |
### Available settings for `services`
...
...
@@ -362,8 +362,8 @@ For example, the following two definitions are equal:
| Setting | Required | GitLab version | Description |
| `name` | yes, when used with any other option | 9.4 | Full name of the image that should be used. It should contain the Registry part if needed. |
| `entrypoint` | no | 9.4 |Command or script that should be executed as the container's entrypoint. It will be translated to Docker's `--entrypoint` option while creating the container. The syntax is similar to [`Dockerfile`'s `ENTRYPOINT`](https://docs.docker.com/engine/reference/builder/#entrypoint) directive, where each shell token is a separate string in the array. |
| `command` | no | 9.4 |Command or script that should be used as the container's command. It will be translated to arguments passed to Docker after the image's name. The syntax is similar to [`Dockerfile`'s `CMD`](https://docs.docker.com/engine/reference/builder/#cmd) directive, where each shell token is a separate string in the array. |
| `entrypoint` | no | 9.4 |Command or script that should be executed as the container's entrypoint. It's translated to Docker's `--entrypoint` option while creating the container. The syntax is similar to [`Dockerfile`'s `ENTRYPOINT`](https://docs.docker.com/engine/reference/builder/#entrypoint) directive, where each shell token is a separate string in the array. |
| `command` | no | 9.4 |Command or script that should be used as the container's command. It's translated to arguments passed to Docker after the image's name. The syntax is similar to [`Dockerfile`'s `CMD`](https://docs.docker.com/engine/reference/builder/#cmd) directive, where each shell token is a separate string in the array. |
| `alias` | no | 9.4 |Additional alias that can be used to access the service from the job's container. Read [Accessing the services](#accessing-the-services) for more information. |
NOTE: **Note:**
...
...
@@ -398,8 +398,8 @@ services:
alias:mysql-2
```
The Runner will still start two containers using the `mysql:latest` image,
however now each of them will also be accessible with the alias configured
The Runner still starts two containers using the `mysql:latest` image,
however now each of them are also accessible with the alias configured
in `.gitlab-ci.yml` file.
### Setting a command for the service
...
...
@@ -408,7 +408,7 @@ in `.gitlab-ci.yml` file.
Let's assume you have a `super/sql:latest` image with some SQL database
inside it and you would like to use it as a service for your job. Let's also
assume that this image doesn't start the database process while starting
assume that this image does not start the database process while starting
the container and the user needs to manually use `/usr/bin/super-sql run` as
a command to start the database.
...
...
@@ -462,8 +462,8 @@ CI jobs:
output.
To override the entrypoint of a Docker image, the recommended solution is to
define an empty `entrypoint` in `.gitlab-ci.yml`, so the Runner doesn't start
a useless shell layer. However, that will not work for all Docker versions, and
define an empty `entrypoint` in `.gitlab-ci.yml`, so the Runner does not start
a useless shell layer. However, that does not work for all Docker versions, and
you should check which one your Runner is using. Specifically:
- If Docker 17.06 or later is used, the `entrypoint` can be set to an empty value.
...
...
@@ -476,8 +476,8 @@ Let's assume you have a `super/sql:experimental` image with some SQL database
inside it and you would like to use it as a base image for your job because you
want to execute some tests with this database binary. Let's also assume that
this image is configured with `/usr/bin/super-sql run` as an entrypoint. That
means that when starting the container without additional options, it will run
the database's process, while Runner expects that the image will have no
means that when starting the container without additional options, it runs
the database's process, while Runner expects that the image has no
entrypoint or that the entrypoint is prepared to start a shell command.
With the extended Docker configuration options, instead of creating your
...
...
@@ -511,7 +511,7 @@ Look for the `[runners.docker]` section:
services=["mysql:latest","postgres:latest"]
```
The image and services defined this way will be added to all job run by
The image and services defined this way are added to all job run by
that runner.
## Define an image from a private Container Registry
...
...
@@ -530,12 +530,12 @@ To define which should be used, the GitLab Runner process reads the configuratio
-`DOCKER_AUTH_CONFIG` variable provided as environment variable in `config.toml` of the Runner.
-`config.json` file placed in `$HOME/.docker` directory of the user running GitLab Runner process.
If the `--user` flag is provided to run the GitLab Runner child processes as unprivileged user,
the home directory of the main GitLab Runner process user will be used.
the home directory of the main GitLab Runner process user is used.
NOTE: **Note:**
GitLab Runner reads this configuration **only** from `config.toml` and ignores it if
it's provided as an environment variable. This is because GitLab Runner uses **only**
`config.toml` configuration and doesn't interpolate **ANY** environment variables at
`config.toml` configuration and does not interpolate **ANY** environment variables at
runtime.
### Requirements and limitations
...
...
@@ -593,9 +593,9 @@ There are two ways to determine the value of `DOCKER_AUTH_CONFIG`:
```
-**Second way -** In some setups, it's possible that Docker client
will use the available system key store to store the result of `docker
uses the available system key store to store the result of `docker
login`. In that case, it's impossible to read `~/.docker/config.json`,
so you will need to prepare the required base64-encoded version of
so you need to prepare the required base64-encoded version of
`${username}:${password}` and create the Docker configuration JSON manually.
Open a terminal and execute the following command:
