Tech Blog.

Thoughts, stories, ideas.

GitLab CI

10. September 2017

Dans cet article en deux parties, nous allons examiner de plus près les fonctionnalités d’intégration continue de GitLab CI.

La première partie est consacrée à l’installation et à la configuration, tandis que la deuxième partie traitera plus en détail des scénarios d’application individuels.

Qu’est-ce que le CI de toute façon ?

CI signifie dans ce cas Intégration Continue et signifie en termes simples qu’un script est exécuté après chaque modification du code source d’un projet.
Dans la plupart des cas, le script CI est déclenché par un système de contrôle de version. Les fichiers créés par ce script peuvent être utilisés plus tard en tant qu’ ‘artefacts de construction’.

Dans de nombreux cas, ce script lance des tests unitaires qui vérifient si les modifications apportées n’affectent pas involontairement d’autres parties du projet.
Les tests unitaires ne sont cependant qu’un scénario parmi d’autres ; un CI peut, par exemple, également construire des packages, créer de la documentation ou même déployer des applications.

GitLab CI

GitLab est une solution Open Source pour Git-Hosting, qui offre également des fonctionnalités CI. Depuis la version 8.2, la partie CI est intégrée dans GitLab et ne doit plus être installée sur un serveur séparé comme auparavant.

Le concept deGitLab CI est basé sur des runners, qui exécutent les scripts de construction proprement dits. GitLab CI est uniquement responsable de l’orchestration de ces coureurs et de la collecte des résultats et des artefacts. Les runners peuvent être des conteneurs docker, des VM ou des machines en métal nu qui ne fonctionnent pas idéalement sur le même serveur que Orchestrator. Cela signifie que les scripts CI n’ont pas accès à GitLab lui-même.

Les coureurs rendent compte à GitLab toutes les quelques secondes via HTTPS et demandent s’il y a un emploi pour eux, GitLab CI ne peut pas contacter les coureurs tout seul.
Cela rend l’installation de nouveaux coureurs beaucoup plus facile, la seule condition est que le coureur puisse se connecter à GitLab via HTTPS.

Le composant runner de GitLab s’appelle `gitlab-ci-multi-runner’[1] et est un binaire compilé statiquement qui supporte Linux, construit sur Windows, OSX et BSD.

Le script CI pour GitLab doit être situé dans le répertoire racine du référentiel respectif et avoir le nom de fichier .gitlab-ci.yml.

Activer le CI pour un projet

Depuis la version 8.2, le composant CI est intégré dans GitLab et activé par défaut. Toutefois, elle peut également être activée ou désactivée pour des projets individuels uniquement.
Le paramètre s’appelle Builds et se trouve dans les paramètres du projet sous Features :

GitLab ne supprime pas les builds et artefacts déjà exécutés lorsque la Feauture est désactivée, mais ne fait que masquer l’élément de menu Builds.

Sous gitlab.example.com/group/repo/builds' ceux-ci sont encore visibles. La suppression de builds est possible via l'interface web. Depuis GitLab 8.9, il est possible de configurer dans.gitlab-ci.yml` combien de temps les résultats et les artefacts sont stockés. [2]

Runner

Setup

Après avoir activé CI dans l’interface web, un runner doit être configuré pour exécuter les builds efficaces. Dans cet exemple, gitlab-ci-multi-runner' est installé sur une machine virtuelle Debian Jessie avec leDocker-Executor`. Dans la deuxième partie de cet article, des informations plus détaillées sur les autres configurations de Runner sont données.

Dans un premier temps, le système devrait être mis à jour :

# apt-get update
# apt-get upgrade

Comme on utilise des patins dockers, il a besoin de dockers en conséquence :

# curl -sSL https://get.docker.com/ | sh

GitLab fournit un script qui configure automatiquement le référentiel. Ceci peut être fait avec la commande suivante :

# curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.deb.sh | sudo bash

Si vous ne voulez pas exécuter des scripts d’Internet de manière incontrôlée, vous pouvez activer le repo de la manière traditionnelle :

# echo "deb https://packages.gitlab.com/runner/gitlab-ci-multi-runner/debian/ jessie main" >> /etc/apt/sources.list
# wget -qO - https://packages.gitlab.com/gpg.key | apt-key add -
# apt-get update

Ensuite, `gitlab-ci-multi-runner’ peut être installé via APT :

# apt-get install gitlab-ci-multi-runner

Ceci configure un service système qui devrait être activé et démarré par défaut (sur les systèmes Debian) :

# systemctl status gitlab-runner.service
● gitlab-runner.service - GitLab Runner
Loaded: loaded (/etc/systemd/system/gitlab-runner.service; enabled)
Active: active (running) since Mon 2016-09-19 18:33:32 CEST; 1 weeks 0 days ago
Main PID: 28102 (gitlab-ci-multi)
CGroup: /system.slice/gitlab-runner.service
└─28102 /usr/bin/gitlab-ci-multi-runner run --working-directory /home/gitlab-runner --config /etc/gitlab-runner/config.toml --service gitlab-runner --syslog...

Le Runner est maintenant prêt et peut être enregistré et utilisé dans des projets.

Register Runner

Le Runner nouvellement installé doit maintenant être enregistré dans GitLab. Chaque projet possède un jeton Runner unique, qui peut être consulté dans l’interface Web sous Project Settings &gt ; Runner :

Ce jeton peut être utilisé pour activer le coureur précédemment configuré. Entrez la commande suivante sur la VM Runner :

# gitlab-ci-multi-runner register \
--url gitlab.example.com
--registration-token L4zpDbiAAA86sDnvYPkn \
--description "CI hello world" \
--executor "docker" \
--docker-image debian:jessie

Paramètre:

  • --url GitLab CI URL
  • --registration-token Registration Token
  • --description Beschreibung des Runners
  • --executor Executor, in diesem Fall Docker
  • --docker-image Docker-Image, sous lequel le Runner fonctionne. Dans cet exemple, un conteneur Jessie est utilisé comme couloir.

Le Runner devrait apparaître dans l’interface web après quelques secondes :

.gitlab-ci.yml

Une fois le runner configuré et enregistré, le fichier `.gitlab-ci.yml’ doit être créé dans le répertoire racine du projet. Dans notre exemple, un seul fichier est créé et testé pour voir s’il existe :

stages:
- test

run-test:
stage: test
script:
- touch foo
- test foo

Après avoir committé et poussé, une compilation en cours d’exécution devrait apparaître sous Builds :

La construction devrait être terminée après quelques secondes :

Vision

Dans la deuxième partie, nous discuterons plus en détail des scénarios d’application Real-Life et présenterons d’autres types de Runner.

Référence

  1. https://gitlab.com/gitlab-org/gitlab-ci-multi-runner
    ↩
  2. https://docs.gitlab.com/ce/ci/yaml/README.html#artifactsexpire_in ↩