Configuring GitLab Runner on OpenShift

This document explains how to configure the GitLab Runner on OpenShift.

Configure a proxy environment

To create a proxy environment:

  1. Edit the custom-env.yaml file. For example:

    apiVersion: v1
    data:
      HTTP_PROXY: example.com
    kind: ConfigMap
    metadata:
      name: custom-env
    
  2. Update OpenShift to apply the changes.

    oc apply -f custom-env.yaml
    
  3. Update your gitlab-runner.yml file.

    apiVersion: apps.gitlab.com/v1beta2
    kind: Runner
    metadata:
      name: dev
    spec:
      gitlabUrl: https://gitlab.example.com
      imagePullPolicy: Always
      token: gitlab-runner-secret # Name of the secret containing the Runner token
      tags: openshift, test
      env: custom-env
    

Add root CA certs to runners

  1. Mount a ConfigMap to the container running the job.

    This uses the GitLab Runner configuration template called custom-config.toml.

    [[runners]]
      [runners.kubernetes]
        [runners.kubernetes.volumes]
          [[runners.kubernetes.volumes.config_map]]
            name = "config-map-1"
            mount_path = "/path/to/directory"
    
  2. Apply the changes.

     oc create configmap custom-config-toml --from-file config.toml=custom-config.toml
    

Configure a custom TLS cert

To set a custom TLS cert, create a secret with key tls.crt and set the ca key in the runner.yaml file.

apiVersion: apps.gitlab.com/v1beta2
kind: Runner
metadata:
  name: dev
spec:
  gitlabUrl: https://gitlab.com
  imagePullPolicy: Always
  token: gitlab-runner-secret # Name of the secret containing the Runner token
  tags: openshift, test
  config: custom-config-toml

Configure the cpu and memory size of runner pods

To set CPU limits and memory limits in a custom config.toml file, follow the instructions in this topic.

Configure job concurrency per runner based on cluster resources

Job concurrency is dictated by the requirements of the specific project.

  1. Start by trying to determine the compute and memory resources required to execute a CI job.
  2. Calculate how many times that job would be able to execute given the resources in the cluster.

If you set too large a concurrency value, Kubernetes still schedules the jobs as soon as it can.