Gitlab-runner

General notes on the usage of Gitab-CI

When using gitab CI for your project, you should be aware, that your CI can be controlled by the .gitlab-ci.yml file, located in the root directory of your repository. That implies that:

• it can be viewed by anyone allowed to view your repository, so do not include any sensitive information. Use instead secret variables to pass sensitive informations to your job, if necessary.

• potentially anybody allowed to commit changes, can alter your .gitlab-ci.yml and by this control your CI jobs. Thus, you need to carefully configure your CI (by means of your .gitlab-ci.yml and your gitlab-project management interface), so that it is only triggered and changed if and by whom you want it to. We recommend to use the rules keyword in your .gitlab-ci.yml to explicitly define what triggers your job (e.g. certain branches, tags etc.).

DKRZ runners

The DKRZ offers a set of instance runners to build and test your code in specific environments and/or build and publish your documentation via gitlab pages.

DKRZ Runners

Description	Tags	Image Details
Runner to build conda or PyPi packages	condaforge, dkrz	click here
Runner to build doxygen pages	doxygen, dkrz	click here
Runner to build sphinx pages	sphinx, dkrz	click here
Runner to build quarto pages	quarto, dkrz	click here
Runner to build latex projects	latex, dkrz	click here
Runner with bare alpine image for own customizations	alpine, dkrz	alpine:latest
Runner accepting arbitrary docker images for small jobs (<10min)	docker-any-image, dkrz	gcr.io/kaniko-project/executor:debug
Runner accepting arbitrary docker images for long jobs (>10min)	docker-any-image-long, dkrz	gcr.io/kaniko-project/executor:debug
Runner providing slurm access to levante; the jobs are executed as the user, who triggered the pipeline	levante, hpc, dkrz	not applicable

These runners can be used by all projects and simply need to be enabled in the respective project under Settings CI/CD Runners. All runners are tagged and only run tagged jobs. That implies, that you need to specify the correct tags in your .gitlab-ci.yml file to use any of the dkrz runners.

We recommend to use our ci-templates, if applicable, in order to ensure that your ci is in line with certain defaults and/or best practices. We also invite you to check and contribute to the examples in our ci-example repository .

The provided runners mostly use docker executors with images created and stored in our gitlab. You can find more details to some of the images here (gitlab login required). You can install additional packages, needed for your project, in the script section of your .gitlab-ci.yml file.

Custom image usage and creation is supported exclusively on the docker-any-image runner. To ensure broad availability across projects and minimize queue times, jobs on this runner are limited to a maximum duration of 10 minutes.

For workloads exceeding this limit, the docker-any-image-long runner is available. This runner imposes no timeout, but operates with stricter resource constraints — expect longer queue and job execution times compared to the standard runner.

Fair Use

Runner resources are shared across all projects. To keep queue times low for everyone, please choose the most appropriate runner for your workload:

• Avoid running large numbers of parallel jobs or long-running jobs on the Docker runners, as this increases queue times and may block the runner entirely. If your job has high resource requirements, the levante runner is the recommended choice.

• Conversely, avoid using a high-resource runner (e.g. levante) for lightweight tasks such as copying files in a pages job, as this can significantly increase your own job’s execution time.

If the offered runner do not satisfy your requirements, you are always free to setup your own runners, or contact support@dkrz.de in case you believe that your requirements would meet the needs of a larger community, making the setup of an additional instance runner feasible. Yet, be aware that we intentially do not offer any docker-in-docker solutions due to the implied security risks.