GitLab CI#

Since we’re using GitLab, we also make extensive use of GitLab CI.

The GitLab CI pipelines are configured via a .gitlab-ci.yml file on the root of your project. GitLab will read this file and run the defined pipelines for you.

Usually you want to run as much tests as possible. This is most likely achieved by running all the make test-* commands in the test stage of the pipeline.

Important

Have a look at the GitLab section and ensure merge requests can not be accepted until the pipeline succeeds. This helps to avoid non-compliant code in the live project.

Shared GitLab CI files#

To configure your GitLab CI pipeline, have a look at the existing projects or the shared GitLab CI files.

The advantages of the shared CI files are:

  • Pipelines are centralised and can (mostly) be managed in a single place

  • Changes and bug fixes must only be applied once (vs. multiple projects)

  • Functionality can be shared used multiple times without repeating yourself (DRY)

  • CI files are modular and can depend on each other

  • Managing the CI/CD process can be done by a single party (i.e. CI/CD expert)

  • Developers only need to refer files by inclusion (no deep CI/CD knowhow required)