• The global section
  • How check_interval works
• The [session_server] section
• The [[runners]] section
  • How clone_url works
• The EXECUTORS
• The SHELLS
• The [runners.docker] section
  • Volumes in the [runners.docker] section
    • Example 1: adding a data volume
    • Example 2: mount a host directory as a data volume
  • Using a private container registry
    • Support for GitLab integrated registry
    • Precedence of Docker authorization resolving
    • Restrict allowed_images to private registry
• The [runners.parallels] section
• The [runners.virtualbox] section
• The [runners.ssh] section
• The [runners.machine] section
  • OffPeakPeriods syntax
• The [runners.custom] section
• The [runners.cache] section
  • The [runners.cache.s3] section
  • The [runners.cache.gcs] section
• The [runners.kubernetes] section
• Helper image
  • Overriding the helper image
• The [runners.custom_build_dir] section
• Note

Advanced configuration

GitLab Runner configuration uses the TOML format.

The file to be edited can be found in:

1. /etc/gitlab-runner/config.toml on *nix systems when GitLab Runner is executed as root (this is also path for service configuration)
2. ~/.gitlab-runner/config.toml on *nix systems when GitLab Runner is executed as non-root
3. ./config.toml on other systems

The global section

This defines global settings of GitLab Runner.

Example:

concurrent = 4
log_level = "warning"

How check_interval works

If there is more than one [[runners]] section in config.toml (let’s call them workers), the interval between requests to GitLab are more frequent than one could expect. GitLab Runner contains a loop that constantly schedules a request that should be made for a worker against the GitLab instance it’s configured for.

GitLab Runner tries to ensure that subsequent requests for one worker will be done in the specified interval, so the value of check_interval is divided by the number of the [[runners]] sections. The loop will next iterate over all sections, schedule a request for each of them, and will sleep for the calculated amount of time. Things get interesting when the workers are tied to a different GitLab instance. Consider the following example.

If one would set check_interval = 10, and there were 2 workers in total (runner-1 and runner-2), a subsequent request would be made each 10 seconds. The loop would look like:

1. Get check_interval value (10s).
2. Get list of workers (runner-1, runner-2).
3. Calculate the sleep interval (10s / 2 = 5s).
4. Start an infinite loop:
   1. Request a job for runner-1.
   2. Sleep for 5s.
   3. Request a job for runner-2.
   4. Sleep for 5s.
   5. Repeat.

So, a request from the Runner’s process is made each 5s. If runner-1 and runner-2 are connected to the same GitLab instance, it means that the request to this GitLab instance will receive a new request from this Runner also each 5s. But as you can see, between the first request for runner-1 and second request for runner-1 there are two sleeps taking 5s, so finally it’s ~10s between subsequent requests for runner-1. The same goes for runner-2. If you define more workers, the sleep interval will be smaller, but a request for a worker will be repeated after all requests for the other workers + their sleeps are called.

The [session_server] section

The section [session_server] is a system runner level configuration, so it should be specified at the root level, not per executor i.e. it should be outside [[runners]] section. The session server allows the user to interact with jobs that the Runner is responsible for. A good example of this is the interactive web terminal.

Both listen_address and advertise_address should be provided in the form of host:port, where host may be an IP address (e.g., 127.0.0.1:8093) or a domain (e.g., my-runner.example.com:8093). The Runner will create a TLS certificate automatically to have a secure connection.

If you want to disable the session server, just delete the [session_server] section and terminal support will be disabled.

Example:

[session_server]
  listen_address = "0.0.0.0:8093" #  listen on all available interfaces on port 8093
  advertise_address = "runner-host-name.tld:8093"
  session_timeout = 1800

The [[runners]] section

This defines one runner entry.

Example:

[[runners]]
  name = "ruby-2.1-docker"
  url = "https://CI/"
  token = "TOKEN"
  limit = 0
  executor = "docker"
  builds_dir = ""
  shell = ""
  environment = ["ENV=value", "LC_ALL=en_US.UTF-8"]
  clone_url = "http://gitlab.example.local"

How clone_url works

In cases where the GitLab instance is exposed to an URL which can’t be used by the runner, a clone_url can be configured. For example; GitLab is exposed to https://gitlab.example.com, but the runner can’t reach that because of a firewall setup. If the runner can reach the node on 192.168.1.23, the clone_url should be set to "http://192.168.1.23.

Only if the clone_url is set, the runner will construct a clone URL in the form of http://gitlab-ci-token:s3cr3tt0k3n@192.168.1.23/namespace/project.git.

The EXECUTORS

There are a couple of available executors currently.

The SHELLS

There are a couple of available shells that can be run on different platforms.

The [runners.docker] section

This defines the Docker Container parameters.

Example:

[runners.docker]
  host = ""
  hostname = ""
  tls_cert_path = "/Users/ayufan/.boot2docker/certs"
  image = "ruby:2.1"
  memory = "128m"
  memory_swap = "256m"
  memory_reservation = "64m"
  oom_kill_disable = false
  cpuset_cpus = "0,1"
  cpus = "2"
  dns = ["8.8.8.8"]
  dns_search = [""]
  privileged = false
  userns_mode = "host"
  cap_add = ["NET_ADMIN"]
  cap_drop = ["DAC_OVERRIDE"]
  devices = ["/dev/net/tun"]
  disable_cache = false
  wait_for_services_timeout = 30
  cache_dir = ""
  volumes = ["/data", "/home/project/cache"]
  extra_hosts = ["other-host:127.0.0.1"]
  shm_size = 300000
  volumes_from = ["storage_container:ro"]
  links = ["mysql_container:mysql"]
  services = ["mysql", "redis:2.8", "postgres:9"]
  allowed_images = ["ruby:*", "python:*", "php:*"]
  allowed_services = ["postgres:9.4", "postgres:latest"]
  [runners.docker.sysctls]
    "net.ipv4.ip_forward" = "1"

Volumes in the [runners.docker] section

You can find the complete guide of Docker volume usage here.

Let’s use some examples to explain how it work (assuming you have a working runner).

Example 1: adding a data volume

A data volume is a specially-designated directory within one or more containers that bypasses the Union File System. Data volumes are designed to persist data, independent of the container’s life cycle.

[runners.docker]
  host = ""
  hostname = ""
  tls_cert_path = "/Users/ayufan/.boot2docker/certs"
  image = "ruby:2.1"
  privileged = false
  disable_cache = true
  volumes = ["/path/to/volume/in/container"]

This will create a new volume inside the container at /path/to/volume/in/container.

Example 2: mount a host directory as a data volume

In addition to creating a volume using a data volume, you can also mount a directory from your Docker daemon’s host into a container. It’s useful when you want to store directories outside the container.

[runners.docker]
  host = ""
  hostname = ""
  tls_cert_path = "/Users/ayufan/.boot2docker/certs"
  image = "ruby:2.1"
  privileged = false
  disable_cache = true
  volumes = ["/path/to/bind/from/host:/path/to/bind/in/container:rw"]

This will use /path/to/bind/from/host of the CI host inside the container at /path/to/bind/in/container.

Using a private container registry

Notes:

• This feature requires GitLab Runner 1.8 or higher
• For GitLab Runner versions >= 0.6, <1.8 there was a partial support for using private registries, which required manual configuration of credentials on runner’s host. We recommend to upgrade your Runner to at least version 1.8 if you want to use private registries.
• Using private registries with the if-not-present pull policy may introduce security implications. To fully understand how pull policies work, read the pull policies documentation.

If you want to use private registries as a source of images for your builds, you can set the authorization configuration in the DOCKER_AUTH_CONFIG variable. It can be set in both GitLab Variables section of a project and in the config.toml file.

For a detailed example, visit the Using Docker images documentation.

The steps performed by the Runner can be summed up to:

1. The registry name is found from the image name.
2. If the value is not empty, the executor will search for the authentication configuration for this registry.
3. Finally, if an authentication corresponding to the specified registry is found, subsequent pulls will make use of it.

Now that the Runner is set up to authenticate against your private registry, learn how to configure .gitlab-ci.yml in order to use that registry.

Support for GitLab integrated registry

Note: To work automatically with private/protected images from GitLab integrated registry it needs at least GitLab CE/EE 8.14 and GitLab Runner 1.8.

Starting with GitLab CE/EE 8.14, GitLab will send credentials for its integrated registry along with the build data. These credentials will be automatically added to registries authorization parameters list.

After this authorization against the registry will be proceed like for configuration added with DOCKER_AUTH_CONFIG variable.

Thanks to this, in your builds you can use any image from you GitLab integrated registry, even if the image is private/protected. To fully understand for which images the builds will have access, read the New CI build permissions model documentation.

Precedence of Docker authorization resolving

As described above, GitLab Runner can authorize Docker against a registry by using credentials sent in different way. To find a proper registry, the following precedence is taken into account:

1. Credentials configured with DOCKER_AUTH_CONFIG.
2. Credentials configured locally on Runner’s host with ~/.docker/config.json or ~/.dockercfg files (e.g., by running docker login on the host).
3. Credentials sent by default with job’s payload (e.g., credentials for integrated registry described above).

The first found credentials for the registry will be used. So for example, if you add some credentials for the integrated registry with the DOCKER_AUTH_CONFIG variable, then the default credentials will be overridden.

Restrict allowed_images to private registry

For certain setups you will restrict access of the build jobs to docker images which comes from your private docker registry. In that case set

[runners.docker]
  ...
  allowed_images = ["my.registry.tld:5000/*:*"]

The [runners.parallels] section

This defines the Parallels parameters.

Example:

[runners.parallels]
  base_name = "my-parallels-image"
  template_name = ""
  disable_snapshots = false

The [runners.virtualbox] section

This defines the VirtualBox parameters. This executor relies on vboxmanage as executable to control VirtualBox machines so you have to adjust your PATH environment variable on Windows hosts: PATH=%PATH%;C:\Program Files\Oracle\VirtualBox.

Example:

[runners.virtualbox]
  base_name = "my-virtualbox-image"
  base_snapshot = "my-image-snapshot"
  disable_snapshots = false

The [runners.ssh] section

This defines the SSH connection parameters.

Example:

[runners.ssh]
  host = "my-production-server"
  port = "22"
  user = "root"
  password = "production-server-password"
  identity_file = ""

The [runners.machine] section

Added in GitLab Runner v1.1.0.

This defines the Docker Machine based autoscaling feature. More details can be found in the separate runners autoscale documentation.

Example:

[runners.machine]
  IdleCount = 5
  IdleTime = 600
  OffPeakPeriods = [
    "* * 0-10,18-23 * * mon-fri *",
    "* * * * * sat,sun *"
  ]
  OffPeakTimezone = "Europe/Berlin"
  OffPeakIdleCount = 1
  OffPeakIdleTime = 3600
  MaxBuilds = 100
  MachineName = "auto-scale-%s"
  MachineDriver = "digitalocean"
  MachineOptions = [
      "digitalocean-image=coreos-stable",
      "digitalocean-ssh-user=core",
      "digitalocean-access-token=DO_ACCESS_TOKEN",
      "digitalocean-region=nyc2",
      "digitalocean-size=4gb",
      "digitalocean-private-networking",
      "engine-registry-mirror=http://10.11.12.13:12345"
  ]

OffPeakPeriods syntax

The OffPeakPeriods setting contains an array of string patterns of time periods represented in a cron-style format. The line contains following fields:

[second] [minute] [hour] [day of month] [month] [day of week] [year]

Like in the standard cron configuration file, the fields can contain single values, ranges, lists and asterisks. A detailed description of the syntax can be found here.

The [runners.custom] section

Define configuration for the custom executor.

The [runners.cache] section

This defines the distributed cache feature. More details can be found in the runners autoscale documentation.

Below is a table containing a summary of config.toml, cli options and ENV variables for register:

The [runners.cache.s3] section

Allows to configure S3 storage for cache. This section contains settings related to S3, that previously were present globally in the [runners.cache] section.

Example:

[runners.cache]
  Type = "s3"
  Path = "path/to/prefix"
  Shared = false
  [runners.cache.s3]
    ServerAddress = "s3.amazonaws.com"
    AccessKey = "AMAZON_S3_ACCESS_KEY"
    SecretKey = "AMAZON_S3_SECRET_KEY"
    BucketName = "runners-cache"
    BucketLocation = "eu-west-1"
    Insecure = false

The [runners.cache.gcs] section

Configure native support for Google Cloud Storage. Read the Google Cloud Storage Authentication documentation to check where these values come from.

Examples:

Credentials configured directly in config.toml file:

[runners.cache]
  Type = "gcs"
  Path = "path/to/prefix"
  Shared = false
  [runners.cache.gcs]
    AccessID = "cache-access-account@test-project-123456.iam.gserviceaccount.com"
    PrivateKey = "-----BEGIN PRIVATE KEY-----\nXXXXXX\n-----END PRIVATE KEY-----\n"
    BucketName = "runners-cache"

Credentials in JSON file downloaded from GCP:

[runners.cache]
  Type = "gcs"
  Path = "path/to/prefix"
  Shared = false
  [runners.cache.gcs]
    CredentialsFile = "/etc/gitlab-runner/service-account.json"
    BucketName = "runners-cache"

The [runners.kubernetes] section

Added in GitLab Runner v1.6.0

This defines the Kubernetes parameters. See Kubernetes executor for additional parameters.

Example:

[runners.kubernetes]
  host = "https://45.67.34.123:4892"
  cert_file = "/etc/ssl/kubernetes/api.crt"
  key_file = "/etc/ssl/kubernetes/api.key"
  ca_file = "/etc/ssl/kubernetes/ca.crt"
  image = "golang:1.8"
  privileged = true
  image_pull_secrets = ["docker-registry-credentials"]
  [runners.kubernetes.node_selector]
    gitlab = "true"

Helper image

When one of docker, docker+machine or kubernetes executors is used, GitLab Runner uses a specific container to handle Git, artifacts and cache operations. This container is created from a special image, named helper image.

The helper image is based on Alpine Linux and it’s provided for amd64 and arm architectures. It contains a gitlab-runner-helper binary which is a special compilation of GitLab Runner binary, that contains only a subset of available commands, as well as Git, Git LFS, SSL certificates store and basic configuration of Alpine.

When GitLab Runner is installed from the DEB/RPM packages, both images (amd64 and arm based) are installed on the host. When the Runner prepares the environment for the job execution, if the image in specified version (based on Runner’s Git revision) is not found on Docker Engine, it is automatically loaded. It works like that for both docker and docker+machine executors.

Things work a little different for the kubernetes executor or when GitLab Runner is installed manually. For manual installations, the gitlab-runner-helper binary is not included and for the kubernetes executor,the API of Kubernetes doesn’t allow to load the gitlab-runner-helper image from a local archive. In both cases, GitLab Runner will download the helper image from Docker Hub, from GitLab’s official repository gitlab/gitlab-runner-helper by using the Runner’s revision and architecture for defining which tag should be downloaded.

Overriding the helper image

In some cases, you may need to override the helper image. There are many reasons for doing this:

1. To speed up jobs execution: In environments with slower internet connection, downloading over and over again the same image from Docker Hub may generate a significant increase of a job’s timings. Downloading the helper image from a local registry (where the exact copy of gitlab/gitlab-runner-helper:XYZ is stored) may speed things up.

2. Security concerns: Many people don’t like to download external dependencies that were not checked before. There might be a business rule to use only dependencies that were reviewed and stored in local repositories.

3. Build environments without internet access: In some cases, jobs are being executed in an environment which has a dedicated, closed network (this doesn’t apply to the kubernetes executor where the image still needs to be downloaded from an external registry that is available at least to the Kubernetes cluster).

4. Additional software: Some users may want to install some additional software to the helper image, like openssh to support submodules accessible via git+ssh instead of git+http.

In any of the cases described above, it’s possible to configure a custom image using the helper_image configuration field, that is available for the docker, docker+machine and kubernetes executors:

[[runners]]
  (...)
  executor = "docker"
  [runners.docker]
    (...)
    helper_image = "my.registry.local/gitlab/gitlab-runner-helper:tag"

Note that the version of the helper image should be considered as strictly coupled with the version of GitLab Runner. As it was described above, one of the main reasons of providing such images is that Runner is using the gitlab-runner-helper binary, and this binary is compiled from part of GitLab Runner sources which is using an internal API that is expected to be the same in both binaries.

The Runner by default references to a gitlab/gitlab-runner-helper:XYZ image, where XYZ is based on the Runner’s architecture and Git revision. Starting with GitLab Runner 11.3 it’s possible to define the version of used image automatically, by using one of the version variables:

[[runners]]
  (...)
  executor = "docker"
  [runners.docker]
    (...)
    helper_image = "my.registry.local/gitlab/gitlab-runner-helper:x86_64-${CI_RUNNER_REVISION}"

With that configuration, GitLab Runner will instruct the executor to use the image in version x86_64-${CI_RUNNER_REVISION}, which is based on its compilation data. After updating the Runner to a new version, this will ensure that the Runner will try to download the proper image. This of course means that the image should be uploaded to the registry before upgrading the Runner, otherwise the jobs will start failing with a “No such image” error.

The [runners.custom_build_dir] section

This section defines custom build directories parameters.

Please notice, that the feature - if not configured explicitly - will be enabled by default for kubernetes, docker, docker-ssh, docker+machine and docker-ssh+machine executors. It will be disabled by default for all other executors.

This feature requires that GIT_CLONE_PATH is within a path defined within runners.builds_dir. For the ease of using builds_dir the $CI_BUILDS_DIR variable can be used.

The feature is by default enabled only for docker and kubernetes executors as they provide a good way to separate resources. This feature can be explicitly enabled for any executor, but special care should be taken when using with executors that share builds_dir and have concurrent > 1.

Example:

[runners.custom_build_dir]
  enabled = true

Note

If you’d like to deploy to multiple servers using GitLab CI, you can create a single script that deploys to multiple servers or you can create many scripts. It depends on what you’d like to do.