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.ymland by this control your CI jobs. Thus, you need to carefully configure your CI (by means of your
.gitlab-ci.ymland 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.).
The DKRZ offers a set of shared and specific runners to build and test your code in specific environments and/or build and publish your documentation via gitlab pages. All runnsers 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.
Nearly all of the dkrz runners use docker executors with images created in 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. For example
.gitlab-ci.yml files, check and contribute to our ci-example repository .
To use one of the specific runner, you need to ask
firstname.lastname@example.org to enable your project for the respective runner. Currently we offer the following specific runners:
- bare alpine image
offers a simple bare alpine image to install your own custom environment tags: alpine, docker