Comment mettre en place un pipeline CI sur GitLab

Cet article traite de la configuration d’un pipeline CI pour un projet C++ sur GitLab. Mes articles précédents couvraient comment mettre en place un système de build basé sur CMake et VSCodium et comment intégrer des tests unitaires basés sur GoogleTest et CTest. Cet article est un suivi de l’extension de la configuration à l’aide d’un pipeline CI. Tout d’abord, je démontre la configuration du pipeline, puis son exécution. Vient ensuite la configuration CI elle-même.

L’intégration continue (CI) signifie simplement que les modifications de code, qui sont validées dans un référentiel central, sont construites et testées automatiquement. Une plate-forme populaire dans le domaine open source pour la mise en place de pipelines CI est GitLab. En plus d’un référentiel Git central, GitLab propose également la configuration de pipelines CI/CD, le suivi des problèmes et un registre de conteneurs.

Termes à connaître

Avant de plonger plus profondément dans ce domaine de la philosophie DevOps, je vais établir quelques termes communs rencontrés dans cet article et le Documentation GitLab:

• Livraison continue (CD) : Provisioning automatique des applications dans le but de les déployer.
• Déploiement continu (CD) : publication automatique de logiciels
• Pipelines : le composant de niveau supérieur pour CI/CD, définit les étapes et les tâches
• Étapes : une collection de travaux qui doivent s’exécuter avec succès
• Jobs : définition des tâches (par exemple, compiler, effectuer des tests unitaires)
• Runners : Services qui exécutent réellement les Jobs

Mettre en place un pipeline CI

Je vais réutiliser les exemples de projets des articles précédents, qui sont disponibles sur GitLab. Pour suivre les étapes décrites dans les chapitres suivants, bifurquez le exemple de projet en cliquant sur le Fourchette bouton, qui se trouve en haut à droite :

Mettre en place un coureur

Pour avoir une idée de la façon dont tout fonctionne ensemble, commencez par le bas en installant un exécuteur sur votre système local.

Suivre la instructions d’installation pour le service d’exécution GitLab pour votre système. Une fois installé, vous devez inscrire un coureur.

1. Sur la page GitLab, sélectionnez le projet et dans le volet de gauche, accédez à Réglages et sélectionnez IC/CD.

2. Développez la section Coureurs et basculez Coureurs partagés éteint (marqueur jaune). Notez le jeton et l’URL (marqueur vert) ; nous en avons besoin à l’étape suivante.

3. Ouvrez maintenant un terminal et entrez gitlab-runner register. La commande appelle un script qui demande une entrée. Voici les réponses :

• Instance GitLab : https://gitlab.com/ (capture d’écran ci-dessus)
• Jeton d’enregistrement : choisissez-le dans Coureurs section (capture d’écran ci-dessus)
• Description : librement sélectionnable
• Balises : Ceci est facultatif. Vous n’avez pas besoin de fournir de balises
• Exécuteur : Choisissez Coquille ici

Si vous souhaitez modifier la configuration ultérieurement, vous pouvez la trouver sous ~/.gitlab-runner/config.toml.

4. Maintenant, démarrez le coureur avec la commande gitlab-runner run. Le coureur attend maintenant des emplois. Votre coureur est maintenant disponible dans le Coureurs section des paramètres du projet sur GitLab :

Exécuter un pipeline

Comme mentionné précédemment, un pipeline est un ensemble de tâches exécutées par le runner. Chaque commit envoyé à GitLab génère un pipeline attaché à ce commit. Si plusieurs commits sont poussés ensemble, un pipeline est créé pour le dernier commit uniquement. Pour démarrer un pipeline à des fins de démonstration, validez et envoyez une modification directement sur l’éditeur Web de GitLab.

Pour le premier test, ouvrez le README.md et ajouter une ligne supplémentaire :

Validez maintenant vos modifications.

Notez que la valeur par défaut est Créer une nouvelle branche. Pour faire simple, choisissez S’engager sur la branche principale.

Quelques secondes après le commit, vous devriez remarquer une sortie dans la fenêtre de la console où le runner GitLab s’exécute :

Checking for jobs... received job=1975932998 repo_url=https://gitlab.com/hANSIc99/cpp_testing_sample.git runner=Z7MyQsA6
Job succeeded duration_s=3.866619798 job=1975932998 project=32818130 runner=Z7MyQsA6

Dans la vue d’ensemble du projet dans GitLab, sélectionnez dans le volet de droite CI/CD –> Pipelines. Vous trouverez ici une liste des pipelines récemment exécutés.

Si vous sélectionnez un pipeline, vous obtenez un aperçu détaillé dans lequel vous pouvez vérifier quelle tâche a échoué (en cas d’échec du pipeline) et voir la sortie des tâches individuelles.

Un travail est considéré comme ayant échoué si une valeur différente de zéro a été renvoyée. Dans le cas suivant, je viens d’invoquer la commande bash exit 1 (ligne 26) pour laisser le travail échouer :

Configuration CI

Les configurations des étapes, des pipelines et des tâches sont effectuées dans le fichier .gitlab-ci.yml à la racine du dépôt. Je recommande de modifier la configuration avec l’éditeur de pipeline intégré de GitLab car il vérifie automatiquement l’exactitude lors de l’édition.

stages:
- build
- test

build:
  stage: build
  script:
    - cmake -B build -S .
    - cmake --build build --target Producer
  artifacts:
    paths:
      - build/Producer

RunGTest:
  stage: test
  script:
    - cmake -B build -S .
    - cmake --build build --target GeneratorTest
    - build/Generator/GeneratorTest

RunCTest:
  stage: test
  script:
    - cmake -B build -S .
    - cd build
    - ctest --output-on-failure -j6

Le dossier définit les étapes construire et test. Ensuite, il définit trois jobs : construire, RunGTest et RunCTest. le construire travail est affecté à l’étape éponyme, et les autres travaux sont affectés à la test étape.

Les commandes sous le scénario section sont des commandes shell ordinaires. Vous pouvez les lire comme si vous les tapiez ligne par ligne dans le shell.

Je tiens à souligner une particularité : artefacts. Dans ce cas, je définis le Producteur binaire comme un artefact de la construire travail. Les artefacts sont téléchargés sur le serveur GitLab et peuvent être téléchargés à partir de là :

Par défaut, les tâches des étapes ultérieures téléchargent automatiquement tous les artefacts créés par les tâches des étapes précédentes.

UNE gitlab-ci.yml référence est disponible sur docs.gitlab.com.

Conclure

L’exemple ci-dessus est élémentaire, mais il montre le principe général de l’intégration continue. Dans la section ci-dessus sur la configuration d’un runner, j’ai désactivé les runners partagés, bien que ce soit la force réelle de GitLab. Vous pouvez créer, tester et déployer votre application dans des environnements propres et conteneurisés. En plus des coureurs disponibles gratuitement pour lesquels GitLab fournit un contingent mensuel gratuit, vous pouvez également fournir vos propres coureurs auto-hébergés basés sur des conteneurs. Bien sûr, il existe également une méthode plus avancée : vous pouvez orchestrer des exécuteurs basés sur des conteneurs à l’aide de Kubernetes, ce qui vous permet d’adapter librement le traitement des pipelines. Vous pouvez en savoir plus sur about.gitlab.com.

Comme j’utilise Fedora, je dois mentionner que Podman n’est pas encore pris en charge en tant que moteur de conteneur pour les coureurs GitLab. Selon le problème de gitlab-runner #27119, le support Podman est déjà sur la liste.

Décrire les étapes récurrentes en tant que tâches et les combiner dans des pipelines et des étapes vous permet de suivre leur qualité sans entraîner de travail supplémentaire. Surtout dans les grands projets communautaires où vous devez décider si les demandes de fusion sont acceptées ou refusées, une approche CI correctement configurée peut vous dire si le code soumis améliorera ou détériorera le projet.