Continuous Integration (CI)¶
Currently, we do not enforce a timeout of jobs on runner side.
The runners are built to best support your scientific projects.
It would be a pity if the generally available offer had to be limited
due to misuse of the platform.
So let us all use the resources for the best!
The Helmholtz GitLab is by default equipped with the possibility to use Continuous Integration for your projects. Several SaaS runners are provided for your projects.
Getting familiar with GitLab CI¶
In order to get started and familiar with GitLab CI we heavily suggest to have a look into any of these resources.
- GitLab CI - Concepts
- GitLab CI - Getting Started
- GitLab CI - Documentation
- GitLab CI - Pipeline Editor
- Assists in creating a valid configuration of GitLab CI
Linux shared runners¶
By default, without specifying a tag, all runners are configured with these properties:
Multiple runners are available to execute your jobs.
If you don’t provide a tag your job will run on any of
the machines listed below.
all concurrent jobs share the available resources.
|Name||Base OS||# CPU cores||Memory||Hard disk||# Concurrent Jobs||Executor||Tags||privileged|
||Flatcar Linux||2||4096 MiB||40 GiB||20||
||Ubuntu||2||8192 MiB||80 GiB||2||
||Ubuntu||2||8192 MiB||80 GiB||2||
||Flatcar Linux||6||16 GiB||40 GiB||1||
If you require additional isolation of your jobs,
is the way to go.
On this runner all your jobs run on a fresh VM in autoscaling mode.
Each instance is used only for one job.
This way it is guaranteed that no jobs affect each other.
privileged refer to?
Usually, Docker Containers are run with
privileged set to
For security reasons, it is in general a bad idea
to use the
A container in
privileged mode is granted extended privileges.
It allows the container nearly all the same access to the host
as processes running outside containers on the host.
privileged mode is a prerequisite to run a
In our setup this is not a security issue: every job is executed in a
fresh VM thrown away after the associated job exited.
Find more information in the
What is autoscaling?
In this mode jobs are executed on machines created on demand. Autoscaling means reduced queue times to spin up CI/CD jobs, and isolated VMs for each job. This isolation of VMs created on-demand also maximizes security as a nice secondary effect, because jobs are not able to interfere with other jobs.
The specific runners are a limited resource which is generally available.
If you do not require the additional features, please do not use them.
It would have a negative impact on the speed of your pipeline.
The runners described above are available in a highly scalable,
low latency way.
Help us to ensure that the resources remain accessible without restrictions.
For certain projects it is useful to test on different hardware or make use of accelerators, e.g. GPUs. This is why we enable you to run your jobs on a set of special purpose runners. We cover four different CPU architectures and two GPU vendors. Below table gives you an information about the available hardware and the tags to use.
|Name||Base OS||Tags||# CPU cores||Memory||Accelerator||CPU architecture||CPU type|
||8||20 GiB||Quadro P5000||
||Intel(R) Xeon(R) Silver 4110|
||8||12 GiB||Radeon RX Vega 64 & Radeon R9 FURY||
||AMD EPYC 7351|
||Cavium ThunderX 88XX|
||32||50 GiB||2 × Tesla P100 SXM2||
Below you find an example of a
.gitlab-ci.yml file using some of the runners
By adding tags to your ob definition you let GitLab know on which runner it
shall schedule your job.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Mac shared runners (Experimental)¶
At the moment an experimental Mac runner is available for testing. If your project requires access, please write a mail. We will do our best to help you setting it up and unterstand the limitations compared to the Linux runners.
Windows shared runners¶
Currently, we do not offer shared Windows runner. As soon as we also support the Windows platform we will let you know.
Feel free to register your own runners for Windows.