GitLab CI/CD

GitLab CI/CD est un outil d'intégration continue et de déploiement continue[1], fourni avec la forge logicielle Gitlab.

GitLab logo.svg

ConfigurationModifier

 
Exemple de pipelines

Un pipeline est un ensemble de jobs déclenché automatiquement après différentes actions manuelles (git push, création de merge request, merge de branche, ou création de tag). Ces jobs peuvent être lancés dans un certain ordre ou en parallèle, selon les étapes (stages) auxquelles ils appartiennent.

IHMModifier

Dans le menu de gauche, cliquer sur CI/CD pour voir les options :

  • Pipelines : liste des groupes de jobs déjà lancés sur le dépôt. On peut les y relancer.
  • Editor : éditeur en ligne du fichier .gitlab-ci.yml du dépôt. Il s'agit du fichier versionné contenant la configuration des pipelines.
  • Jobs : liste de tous les jobs.
  • Schedules : gestion des tâches planifiées.

.gitlab-ci.ymlModifier

Pour qu'un pipeline se lance par hook dans un dépôt, il doit contenir un fichier .gitlab-ci.yml à la racine.

Exemple simpleModifier

stages:
  - build

build-code:
  stage: build
  script:
    - echo "Hello World!"
    - pwd; ls -alh

before_scriptModifier

Script à exécuter avant chaque job.

variablesModifier

Variables appelables plusieurs fois au sein du .gitlab-ci.yml. Certaines permettent de configurer le comportement de GitLab CI. Exemple :

GIT_STRATEGYModifier

Politique de clonage :

  • none : pas de clone (ex : si on utilise une image Docker).
  • fetch : clone différentiel depuis le dernier.
  • clone : clone à partir de zéro[2].

La valeur par défaut est définie dans l'IHM : /settings/ci_cd.

GIT_DEPTHModifier

Définit la profondeur lors du clone du dépôt : shallow clone[3].

Dans un jobModifier

stageModifier

Étape qui lancera le job.

scriptModifier

Script à lancer.

onlyModifier

Liste des branches où le job peut s'exécuter (lors des merges).

Exemple complexeModifier

stages:
  - build
  - test
  - publish
  - deploy

DebugModifier

Vérifier les valeurs des variables[4] :

build-code:
  stage: build
  script:
    - export

DéploiementsModifier

 
Liste des runners.

Déploiement de test à chaque Merge RequestModifier

À chaque Merge Request (alias Pull Request, ou PR, ou MR), un job est créé pour lancer les instructions du .gitlab-ci.yml dans l'ordre. Mais avant de se lancer, il doit attendre la disponibilité d'un serveur de test sur lequel s'exécuter, appelé "runner"[5].

Les runners peuvent être fournis par GitLab ou installés soi-même. Dans ce cas leur configuration se trouve dans un fichier .toml.

A partir d'une image Docker du registreModifier

Le principe consiste à envoyer une image Docker dans le registre GitLab pour que les conteneurs puissent l'utiliser ensuite sans avoir à le reconstruire.

$CI_REGISTRY_IMAGE représente l'URL du registre, ex : https://registry.gitlab.com/mon_espace.

Via DockerModifier

image: docker:latest

Via Docker-composeModifier

Utile en cas de communication entre plusieurs conteneurs.

image: docker/compose:1.27.4

Via KanikoModifier

Si les conteneurs déployés le sont dans un autre conteneur, cela peut occasionner des problèmes de performances. Kaniko est un système pour éviter cela[6].

 image:
   name: gcr.io/kaniko-project/executor:debug

RéférencesModifier

Voir aussiModifier

Cette page constitue un livre entier. 

Cette page constitue un livre entier.