Mentions légales du service

Skip to content
Snippets Groups Projects
G

gitlabci_gallery

Refer to presentation for more info about this group

README.md

Gitlab-CI Gallery: Introduction

The Gallery is a public list of "real life" gitlab-ci examples. It contains several subgroups and git repositories showing some interesting key features of gitlab-ci and possible integrations with external tools/platforms (ci.inria.fr, terraform, github, a supercomputer, etc).

Overview

Under the global gitlab_gallery group you will find the following sub-groups containing the example projects:

  • windows: here are CI examples with shared runners on Windows OS.
  • testing: this subgroup contains examples that demonstrates how to run tests on CI and use test reports and coverage feature in different languages and architectures.
  • release: this subgroup contains examples that demonstrates how to automate release publication.
  • pipelines: in this subgroup one will find full CI pipelines examples that show some jobs organization (parallel, sequence, dependencies...).
  • orchestration: this subgroup is about runners ochestration: how to finely manage, from CI, the VMs and associated runners for your jobs.
  • logs: this subgroup contains examples that shows how to exploit CI generated logs.
  • latex: you will find here examples of latex compilations in the CI.
  • gitlab-api: here are examples of direct gitlab api use in CI.
  • github-actions: this subgroups demonstrates how to run github actions in gitlab-ci.
  • documentation-pages: you will find here some examples of documentation generation in the pages by the CI.
  • docker: here are some examples of how to properly use docker images in CI.
  • dashboards: examples for saving and monitoring test metrics over time.

For searching a project, you can:

Gitlab search in group seems to use fuzzy matching on words in project description for getting results. If you want your project to be associated to a specific keyword, put it in your project description, e.g., Keywords: gitlabci, release, lint, c++.

Prerequisites

Enable project CI/CD feature

All projects in the Gitlab-CI Gallery use Gitlab CI/CD. If you want to reproduce in your own project the behavior illustrated in a project in this gallery, you should first enable the CI/CD project feature.

  • On the left sidebar in the Gitlab interface, go to Settings → General.
  • Expand Visibility, project features, permissions.
  • In the Repository section, turn on CI/CD.
  • Select Save changes.

These steps are given in the Gitlab documentation.

Enable shared runners

Most projects in the Gitlab-CI Gallery use shared runners. If you want to reproduce in your own project the behavior illustrated in such a project, you should enable shared runners.

  • On the left sidebar in the Gitlab interface, go to Settings → CI/CD. If you don't have a CI/CD item, then you should enable project CI/CD feature first.
  • Expand Runners.
  • In the Shared runners section, turn on Enable shared runners for this project.

These steps are given in the Gitlab documentation.

Enable container registry

Some projects require the container registry to store and use docker containers.

  • On the left sidebar in the Gitlab interface, go to Settings → General.
  • Expand Visibility, project features, permissions.
  • Turn on Container registry.
  • Select Save changes.

Gitlab container registry is documented in the Gitlab documentation.

CI/CD Variables

Some projects require to set CI/CD variables.

  • On the left sidebar in the Gitlab interface, go to Settings → CI/CD. If you don't have a CI/CD item, then you should enable project CI/CD feature first.
  • Expand Variables.
  • Select Add variable.
  • Fill the fields for Key (the variable name), Value, Type (either Variable or File).
    • Variables of type Variable carry directly the value specified in the field Value.
    • Variables of type File carry the path to a filename, where the contents of the field Value is stored.
    • For secrets stored as variables, if these secrets are not to be shared with all develepers, then the Protect variable should be checked so that they can only be used in branches controlled by project maintainers, to prevent other developers to reveal these secrets in their pipelines Beware that non-protected branches can then become broken if these variables are essential for the jobs to succeed: rules of the form rules: - if: $VAR can be added to enable some jobs only if $VAR is available. Protected branches can be set up in Settings → Repository → Protected branches.
    • The Mask variable should be checked if the value contains a secret and can appear in job output, to mask it in the logs.
    • In the values of the variables used in this gallery, we don't use references to other variables, so Expand variable reference is irrelevant.
  • Select Add variable.

These steps are given in the Gitlab documentation.