Registering runners
Offering: GitLab.com, Self-managed
- Introduced in GitLab Runner 15.0, a change to the registration request format prevents the GitLab Runner from communicating with GitLab 14.7 and earlier. You must use a GitLab Runner version that is appropriate for the GitLab version, or upgrade the GitLab application.
Runner registration is the process that links the runner with one or more GitLab instances. You must register the runner so that it can pick up jobs from the GitLab instance.
Requirements
Before you register a runner:
- Install GitLab Runner on a server separate to where GitLab is installed.
- For runner registration with Docker, install GitLab Runner in a Docker container.
Register with a runner authentication token
- Introduced in GitLab 15.10.
Prerequisites:
- Obtain a runner authentication token. You can either:
After you register the runner, the configuration is saved to the config.toml
.
To register the runner with a runner authentication token:
-
Run the register command:
sudo gitlab-runner register
If you are behind a proxy, add an environment variable and then run the registration command:
export HTTP_PROXY=http://yourproxyurl:3128 export HTTPS_PROXY=http://yourproxyurl:3128 sudo -E gitlab-runner register
- Enter your GitLab URL:
- For runners on GitLab self-managed, use the URL for your GitLab instance. For example,
if your project is hosted on
gitlab.example.com/yourname/yourproject
, your GitLab instance URL ishttps://gitlab.example.com
. - For runners on GitLab.com, the
gitlab-ci coordinator URL
ishttps://gitlab.com
.
- For runners on GitLab self-managed, use the URL for your GitLab instance. For example,
if your project is hosted on
- Enter the runner authentication token.
- Enter a name for the runner.
- Enter the type of executor.
- To register multiple runners on the same host machine, each with a different configuration,
repeat the
register
command. - To register the same configuration on multiple host machines, use the same runner authentication token for each runner registration. For more information, see Reusing a runner configuration.
You can also use the non-interactive mode to use additional arguments to register the runner:
sudo gitlab-runner register \
--non-interactive \
--url "https://gitlab.com/" \
--token "$RUNNER_TOKEN" \
--executor "docker" \
--docker-image alpine:latest \
--description "docker-runner"
Register with a runner registration token (deprecated)
Prerequisites:
After you register the runner, the configuration is saved to the config.toml
.
To register the runner with a runner registration token:
-
Run the register command:
sudo gitlab-runner register
If you are behind a proxy, add an environment variable and then run the registration command:
export HTTP_PROXY=http://yourproxyurl:3128 export HTTPS_PROXY=http://yourproxyurl:3128 sudo -E gitlab-runner register
- Enter your GitLab URL:
- For GitLab self-managed runners, use the URL for your GitLab instance. For example,
if your project is hosted on
gitlab.example.com/yourname/yourproject
, your GitLab instance URL ishttps://gitlab.example.com
. - For GitLab.com, the
gitlab-ci coordinator URL
ishttps://gitlab.com
.
- For GitLab self-managed runners, use the URL for your GitLab instance. For example,
if your project is hosted on
- Enter the token you obtained to register the runner.
- Enter a description for the runner.
- Enter the job tags, separated by commas.
- Enter an optional maintenance note for the runner.
- Enter the type of executor.
To register multiple runners on the same host machine, each with a different configuration,
repeat the register
command.
You can also use the non-interactive mode to use additional arguments to register the runner:
sudo gitlab-runner register \
--non-interactive \
--url "https://gitlab.com/" \
--registration-token "$PROJECT_REGISTRATION_TOKEN" \
--executor "docker" \
--docker-image alpine:latest \
--description "docker-runner" \
--maintenance-note "Free-form maintainer notes about this runner" \
--tag-list "docker,aws" \
--run-untagged="true" \
--locked="false" \
--access-level="not_protected"
-
--access-level
creates a protected runner.- For a protected runner, use the
--access-level="ref_protected"
parameter. - For an unprotected runner, use
--access-level="not_protected"
or leave the value undefined.
- For a protected runner, use the
-
--maintenance-note
adds information related to runner maintenance. The maximum length is 255 characters.
Legacy-compatible registration process
- Introduced in GitLab 16.2.
Runner registration tokens and several runner configuration arguments were deprecated
in GitLab 15.6 and will be removed in GitLab 18.0. To ensure minimal disruption to your automation workflow, the legacy-compatible registration process
triggers
if a runner authentication token is specified in the legacy parameter --registration-token
.
The legacy-compatible registration process ignores the following command-line parameters. These parameters can only be configured when a runner is created in the UI or with the API.
--locked
--access-level
--run-untagged
--maximum-timeout
--paused
--tag-list
--maintenance-note
Register with a configuration template
You can use a configuration template to register a runner with settings that are not supported by the register
command.
Prerequisites:
- The volume for the location of the template file must be mounted on the GitLab Runner container.
- A runner authentication or registration token:
The configuration template can be used for automated environments that do not support some arguments
in the register
command due to:
- Size limits on environment variables based on the environment.
- Command-line options that are not available for executor volumes for Kubernetes.
[[runners]]
section and does not support global options.To register a runner:
-
Create a configuration template file with the
.toml
format and add your specifications. For example:[[runners]] [runners.kubernetes] [runners.kubernetes.volumes] [[runners.kubernetes.volumes.empty_dir]] name = "empty_dir" mount_path = "/path/to/empty_dir" medium = "Memory"
-
Add the path to the file. You can use either:
-
The non-interactive mode in the command line:
$ sudo gitlab-runner register \ --template-config /tmp/test-config.template.toml \ --non-interactive \ --url "https://gitlab.com" \ --token <TOKEN> \ "# --registration-token if using the deprecated runner registration token" --name test-runner \ --executor kubernetes --host = "http://localhost:9876/"
-
The environment variable in the
.gitlab.yaml
file:variables: TEMPLATE_CONFIG_FILE = <file_path>
If you update the environment variable, you do not need to add the file path in the
register
command each time you register. -
After you register the runner, the settings in the configuration template
are merged with the [[runners]]
entry created in the config.toml
:
concurrent = 1
check_interval = 0
[session_server]
session_timeout = 1800
[[runners]]
name = "test-runner"
url = "https://gitlab.com"
token = glrt-<TOKEN>
executor = "kubernetes"
[runners.kubernetes]
host = "http://localhost:9876/"
bearer_token_overwrite_allowed = false
image = ""
namespace = ""
namespace_overwrite_allowed = ""
privileged = false
service_account_overwrite_allowed = ""
pod_labels_overwrite_allowed = ""
pod_annotations_overwrite_allowed = ""
[runners.kubernetes.volumes]
[[runners.kubernetes.volumes.empty_dir]]
name = "empty_dir"
mount_path = "/path/to/empty_dir"
medium = "Memory"
Template settings are merged only for options that are:
- Empty strings
- Null or non-existent entries
- Zeroes
Command-line arguments or environment variables take precedence over
settings in the configuration template. For example, if the template
specifies a docker
executor, but the command line specifies shell
,
the configured executor is shell
.
Register a runner for GitLab Community Edition integration tests
To test GitLab Community Edition integrations, use a configuration template to register a runner with a confined Docker executor.
- Create a project runner.
-
Create a template with the
[[runners.docker.services]]
section:$ cat > /tmp/test-config.template.toml << EOF [[runners]] [runners.docker] [[runners.docker.services]] name = "mysql:latest" [[runners.docker.services]] name = "redis:latest" EOF
-
Register the runner:
sudo gitlab-runner register \ --non-interactive \ --url "https://gitlab.com" \ --token "$RUNNER_AUTHENTICATION_TOKEN" \ --template-config /tmp/test-config.template.toml \ --description "gitlab-ce-ruby-2.7" \ --executor "docker" \ --docker-image ruby:2.7
For more configuration options, see Advanced configuration.
Registering runners with Docker
After you register the runner with a Docker container:
- The configuration is written to your configuration volume. For example,
/srv/gitlab-runner/config
. - The container uses the configuration volume to load the runner.
gitlab-runner restart
runs in a Docker container, GitLab Runner starts a new process instead of restarting the existing process.
To apply configuration changes, restart the Docker container instead.Troubleshooting
Check registration token
error
The check registration token
error message displays when the GitLab instance does not recognize
the runner registration token entered during registration. This issue can occur when either:
- The instance, group, or project runner registration token was changed in GitLab.
- An incorrect runner registration token was entered.
When this error occurs, you can ask a GitLab administrator to:
- Verify that the runner registration token is valid.
- Confirm that runner registration in the project or group is permitted.