GitLab CI/CD

GitLab provides a continuous integration and deployment toolchain called GitLab CI/CD. Information concerning continuous integration (pipelines, jobs, environments, etc.) is displayed in the [CI/CD] tab of the GitLab vertical menu.

The IN2P3 Gitlab instance provides its users with a set of Gitlab runners, both in x64 and ARM architectures, in order for them to run their CI/CD jobs. However, these instance runners (also refered to as public runners) are shared among several thousand Gitlab users and their ressources are strictly limited. These runners are unprivileged. As such, they are unable to run Docker-in-Docker jobs. Please refer to the administrators notes for more information.

Moreover, the confidentiality of the code and data processed by these CI jobs is not assured since the underlying ressources are inherently shared among CI users. Lastly, each job resources are limited to some extent, ensuring fair resource usage and limiting abuses.

Important

Each job can use up to 4 vCPU and 2GB of memory. A job will timeout after 1 hour: if it takes longer to execute, it will fail.

Build a CI/CD infrastructure

Public runners are made available for free to all the users of the IN2P3 Gitlab instance, to be used for learning purposes and grasping the basics of Gitlab CI. Of course, any use case dealing with extensive software integration or production workloads requiring specific runner configuration or higher resources should always imply the setup of a dedicated Gitlab CI infrastructure.

You can easily deploy and use your own Gitlab CI infrastructure for your projects. More information is available on the Gitlab documentation.

Note

When using your own CI/CD infrastructure (ie. your own runners) it is advised to disable instance runners at the project or group level in order to avoid jobs to be picked up by the fastest of the instance or private runners. Please refer to the Selecting runners paragraph.

In the event when you do not have access to the necessary computing ressources to set up such an infrastructure, and your project is part of a collaboration supported by IN2P3, you may request resources on the CC-IN2P3 infrastructure.

For any issue or request, please contact our user support.

Selecting runners

Users may select which runners will pick up CI/CD jobs in their Gitlab project through the CI/CD settings menu. Moreover, finer selection may be done with the tags keyword in your gitlab CI configuration file.

Jobs that do not use the tag keyword are considered as “untagged” and may only be picked up by runners that are allowed to pick up untagged jobs.

Gitlab IN2P3 instance runners use the following tags:

Instance runners tags
Type	Will pick up untagged jobs ?	Limits per job	Architecture	Associated tags
public	yes	4 vCPUs, 2GB RAM	x64	`ccin2p3`, `x64`
public-arm	no	4vCPUs, 2GB RAM	ARM	`ccin2p3`, `ARM`

Here is an exemple of a job that can be picked up by a public ARM runner:

---
job1:
  tags:
    - ccin2p3
    - arm
  script:
    - echo 'Slacking off at work!'

Attention

Using the ccin2p3 tag alone will result in unpredictable behavior: jobs may be picked up by any public runner.