Skip to content

CI / CD

What

A Gitlab runner is a physical agent, running on either a server or a local machine, able to:

  • Select a base image from precompiled ones or use custom Dockerfile files to build one
  • Download the copy of a Gitlab project
  • Execute the given tasks specified by the .gitlab-ci.yml file
  • Upload the results to the Gitlab server

It can be used to do continuous integration, continuous deployment, doc generation, cross-platforms compilations, Gitlab pages generation ...

SPL runners

Runner type

Runners are differentiated by their scope:

  • Project: Runner dedicated to a (single) project. The runner must be activated manually for each project that needs it.
  • Group: Runner dedicated to a group of projects, here the SPL group. The runner activates automatically for all projects created under the group.
  • Instance: Runner dedicated to the whole Gitlab instance. It is shared by all projects and groups. Active by default for all projects.

Available

The SPL group can use the following runners:

Name Description Tags Executor Scope Manager
Apollon Runner SPL Gitlab Project Runner, running on Apollon cluster. Apollon, Docker, Linux, SPL, x86_64 docker Project SPL
Apollon Runner SPL Gitlab Group Runner, running on Apollon cluster. Apollon, Docker, Linux, SPL, x86_64 docker Group SPL
Dell Runner SPL Gitlab Project Runner, running on Dell local PC. Docker, Linux, Local, SPL, x86_64 docker Project SPL
Dell Runner SPL Gitlab Group Runner, running on Dell local PC. Docker, Linux, Local, SPL, x86_64 docker Group SPL
Shared GitLab Runner Shared GitLab Runner on Apollon. apollon, docker, linux docker Instance ClM

Custom runners

If you need a custom runner (different host architecture, CD testing ...), use the Local Gitlab Runner repository to help you set up one.

It contains:

  • install-apollon-no-did.sh: a script to install on an Apollon instance, which can be used as a base to install on another Linux server instance
  • setup.xxx: a script to build a custom runner image through a Dockerfile, which can then be ran on any machine through Docker. The Gitlab runner image runs itself a Docker instance for CI jobs, doing Docker-in-Docker (DinD)

More documentation can be found in the repository.

Managing custom runners life cycles

Each person creating runners is responsible for their life cycle:

  • Creation: where the runner is created, with which scope
  • Usage: on which projects or groups the runner is activated, how it picks up jobs
  • Deletion: when the runner is not needed anymore, unregister it from the Gitlab instance

Note

Did not follow the repository naming convention and cannot find the root of a runner to delete it ?

  • Go to the root of a group where the runner can be activated
  • Go to Build \(\rightarrow\) Runners
  • The column Owner tells where the runner is registered

SPL runners management

Local, Dell runner

The runner is a local PC which allows for bigger images and continuous deployment to be performed.

It is available in room 23.N.313 running Ubuntu, performing up to 6 parallel jobs.

It is configured by using DinD through the custom Dockerfile image.

Registration roots

The group runner is registered under the SPL group.

The project runner is under the Local Gitlab Runner repository.

Start runner service

  • Open a sessions on the Dell PC
  • Run Docker and ensure the gitlab-runner container is running
  • The PC can be locked while maintaining the runner service

Apollon, cluster runner

The runner is an Apollon cluster node which allows for small images to be executed with up to 4 parallel jobs.

It is configured through the install-apollon-no-did.sh script.

Registration roots

The group runner is registered under the SPL group.

The project runner is under the Local Gitlab Runner repository.

Start runner service

The node is configured to automatically launch the gitlab-runner service at boot.

If for any reason the service fails to start, you can:

  • Open a session on the Apollon node: ssh -J jump@apollon.hevs.ch ubuntu@<node_ip>
  • Restart the services: sudo systemctl restart docker && sudo systemctl restart gitlab-runner
  • Check the status: sudo systemctl status docker && sudo systemctl status gitlab-runner

Lease and reinstallation

Since the lease of the node is limited, the runner must be reinstalled every now and then.

Use the install-apollon-no-did.sh script to reinstall it:

  • Create a lease with 2 vCPU, 4 GB RAM, 40 GB disk
  • Create image and setup IP from pool
  • Copy / clone and run the install-apollon-no-did.sh script on the remote
  • Test that the CI correctly picks up and execute jobs
  • Setup a new reminder / Notion card to reinstall the runner when next lease is due

Note

To avoid generating and reinstalling new Gitlab tokens, the same ones can be reused by copying the /etc/gitlab-runner/config.toml file from the old runner to the new one.

Also, the token may be passed with the reminder / Notion card.