- Deploying a stand-alone runner
- Using Docker-in-Docker
- Installation command line options
- Chart configuration examples
Using the GitLab Runner chart
The GitLab Runner subchart provides a GitLab Runner for running CI jobs. It is enabled by default and should work out of the box with support for caching using s3 compatible object storage.
This chart depends on the shared-secrets subchart to populate its
registrationToken for automatic registration. If you intend to run this chart as a stand-alone chart with an existing GitLab instance then you will need to manually set the
registrationToken in the
gitlab-runner secret to be equal to that displayed by the running GitLab instance.
There are no required settings, it should work out of the box if you deploy all of the charts together.
Deploying a stand-alone runner
By default we do infer
gitlabUrl, automatically generate a registration token, and generate it through the
migrations chart. This behavior will not work if you intend to deploy it with a running GitLab instance.
In this case you will need to set
gitlabUrl value to be the URL of the running GitLab instance. You will also need to manually create
gitlab-runner secret and fill it with the
registrationToken provided by the running GitLab.
In order to run Docker-in-Docker, the runner container needs to be privileged to have access to the needed capabilities. To enable it set the
privileged value to
true. See the upstream documentation in regards to why this is does not default to
Privileged containers have extended capabilities, for example they can mount arbitrary files from the host they run on. Make sure to run the container in an isolated environment such that nothing important runs beside it.
Installation command line options
|Install the |
|Image pull policy|
|Secrets for the image repository|
|Unregister all runners before termination|
|Number of concurrent jobs|
|Whether to create rbac service account|
|Deploy containers of jobs cluster-wide|
|Name of the rbac service account to create|
|Default container image to use in builds|
|Run in privileged mode, needed for |
|Namespace to run jobs in|
|Name of the bucket|
|Share the cache between runners|
|Secret to access key and secretkey from|
|Path in the bucket|
|Build container cpu limit|
|Build container memory limit|
|Build container requested cpu|
|Build container requested memory|
|Service container cpu limit|
|Service container memory limit|
|Service container requested cpu|
|Service container requested memory|
|Runner cpu limit|
|Runner memory limit|
|Runner requested cpu|
|Runner requested memory|
Chart configuration examples
pullSecrets allow you to authenticate to a private registry to pull images for a pod.
Additional details about private registries and their authentication methods can be found in the Kubernetes documentation.
Below is an example use of
image: my.runner.repository imagePullPolicy: Always pullSecrets: - name: my-secret-name - name: my-secondary-secret-name