GitLab CI


GitLab CI is a powerful Continuous Integration system integrated into GitLab.

The tasks of the CI system are configured in scripts inside the OGS source code. The entry point is defined in .gitlab-ci.yml. Scripting and versioning the configuration together with the source code is very powerful, e.g. if you introduce a new OGS CMake configuration in a merge request even the change of the CI jobs configuration or jobs environment (Docker container definition) can be part of the merge request.

GitLab Pipeline

A CI run consists of a pipeline which contains stages which in turn contain jobs. A job runs a set of instructions (e.g. checking out the source code, building the code, testing the code) on a runner.

Each pipeline run is visualized as follows: GitLab pipeline visualization

Jobs belong to a stage and each job will get a status (success, warnings, failure). Some jobs are optional (see the gear icon) and can be manually triggered by pressing the play button.

Some jobs run on native servers (e.g. on the envinf[1,2,3] Linux servers) and some run in Docker containers.

Automatic testing

The master-branch of the main repository as well as all merge requests on that repository are automatically tested. See the pipelines page.

Skip automatic testing

If you want to skip a pipeline run for a push add the -o ci.skip git push option. Example:

git push -o ci.skip

Or add [ci skip] to the commit message to skip the pipeline for this commit. Example:

git commit -m "Added feature X [ci skip]"

Automatic testing for own repository


This article was written by Lars Bilke. If you are missing something or you find an error please let us know.
Generated with Hugo 0.101.0 in CI job 262272 | Last revision: October 24, 2022
Commit: [web] Update docs on notebook testing and web conversion. 1cb932f  | Edit this page on