For compatibility reasons, the GitLab Runner
major.minor
version
should stay in sync with the GitLab major and minor version. Older runners may still work
with newer GitLab versions, and vice versa. However, features may not be available or work properly
if a version difference exists.
Backward compatibility is guaranteed between minor version updates. However, sometimes minor
version updates of GitLab can introduce new features that require GitLab Runner to be on the same minor
version.
GitLab Runner 15.0
introduced
a change to the
registration API request format. It prevents the GitLab Runner from communicating with GitLab versions lower than 14.8.
You must use a Runner version that is appropriate for the GitLab version, or upgrade the GitLab application.
If you host your own runners but host your repositories on GitLab.com,
keep GitLab Runner
updated
to the latest version, as GitLab.com is
updated continuously
.
When you register a runner, you are setting up communication between your
GitLab instance and the machine where GitLab Runner is installed.
Runners usually process jobs on the same machine where you installed GitLab Runner.
However, you can also have a runner process jobs in a container,
in a Kubernetes cluster, or in auto-scaled instances in the cloud.
An
executor
determines the environment each job runs in.
For example:
If you want your CI/CD job to run PowerShell commands, you might install GitLab
Runner on a Windows server and then register a runner that uses the shell executor.
If you want your CI/CD job to run commands in a custom Docker container,
you might install GitLab Runner on a Linux server and register a runner that uses
the Docker executor.
These are only a few of the possible configurations. You can install GitLab Runner
on a virtual machine and have it use another virtual machine as an executor.
When you install GitLab Runner in a Docker container and choose the
Docker executor
to run your jobs, it’s sometimes referred to as a “Docker-in-Docker” configuration.
When a CI/CD job runs, it knows which runner to use by looking at the assigned tags.
Tags are the only way to filter the list of available runners for a job.
For example, if a runner has the
ruby
tag, you would add this code to
your project’s
.gitlab-ci.yml
file:
job:tags:-ruby
When the job runs, it uses the runner with the
ruby
tag.
Configuring runners
You can
configure
the runner by editing the
config.toml
file. This is a file that is installed during the runner installation process.
In this file you can edit settings for a specific runner, or for all runners.
You can specify settings like logging and cache. You can set concurrency,
memory, CPU limits, and more.
Monitoring runners
You can use Prometheus to
monitor
your runners.
You can view things like the number of currently-running jobs and how
much CPU your runners are using.
If you didn't find what you were looking for,
search the docs
.
If you want help with something specific and could use community support,
post on the GitLab forum
.
For problems setting up or using this feature (depending on your GitLab
subscription).
