Guide de démarrage rapide pour une intégration continue avec GitLab

Au sein d'un projet, vous pouvez gérer différents composants tels que votre code source, la configuration de l'intégration continue, la planification, l'analyse des données ainsi que les membres de l'équipe. Dans ce guide, nous allons créer un nouveau projet vierge, contenant uniquement un fichier README.

• Créez un nouveau projet en cliquant sur le bouton « + » sur le côté droit de la barre supérieure, et sélectionnez Nouveau projet/dépôt.
• Sélectionnez Créer un projet vide. Sous Nom du projet, saisissez mon-projet.
• Cliquez sur Créer le projet.
• Félicitations ! Vous avez créé votre premier projet.

Dans GitLab, la configuration CI est définie directement dans le code à l'aide de la syntaxe YAML et sert à transmettre des instructions au runner concernant, par exemple, l'exécution, l'ordre ou les conditions des jobs. Pour définir la configuration CI, vous devez créer un fichier nommé .gitlab-ci.yml, placé à la racine de votre dépôt. Dans ce guide, nous utiliserons le Web IDE pour créer et modifier ce fichier.

Pour accéder au Web IDE, il vous suffit de cliquer sur le bouton d'accès rapide « WebIDE » situé dans votre projet. Une fois le Web IDE ouvert, accédez à l'explorateur de fichiers sur le côté gauche. Faites un clic droit dans l'explorateur de fichiers et choisissez l'option Nouveau fichier. Nommez ce nouveau fichier .gitlab-ci.yml.

L'ordre d'exécution des jobs est déterminé par les étapes définies dans la configuration. Dans ce guide, nous définirons trois étapes : le build, le test et l'empaquetage, dans cet ordre précis. Copiez-collez le code suivant dans le fichier .gitlab-ci.yml :

        stages:
    - build
    - test
    - package

    

Supposons que vous deviez créer deux fichiers texte. Il est impératif que la concaténation de ces deux fichiers contienne la phrase « Hello world ». Notre objectif est de gérer cette exigence à travers les jobs d'un pipeline contenant les étapes de build, de test et d'empaquetage.

Nous allons spécifier un job de build qui accomplit les tâches suivantes : créer un premier fichier texte contenant le mot « Hello », créer un deuxième fichier texte contenant le mot « World » et générer un troisième fichier qui stocke le contenu combiné des deux fichiers précédents. Ce dernier fichier est enregistré en tant qu'artefact, afin qu'il puisse être utilisé lors des jobs dans les étapes suivantes du pipeline, notamment pour les tests et l'empaquetage. Ajoutez le code ci-dessous sous le bloc d'étapes :

        build-job:
    stage: build
    script:
      - echo "Hello " | tr -d "\n" > file1.txt
      - echo "world" > file2.txt
      - cat file1.txt file2.txt > compiled.txt
    artifacts:
    paths:
      - compiled.txt

    

Pour valider l'intégrité de notre build, nous allons intégrer un job de test qui vérifiera si le fichier compiled.txt contient bien la phrase « Hello world ». Ajoutez le code suivant sous le job de build :

        test:
    stage: test
    script: cat compiled.txt | grep -q 'Hello world '

    

Une fois ce test réussi, notre prochain objectif consiste à empaqueter notre code. Pour ce faire, nous devons inclure un job d'empaquetage. Veuillez noter que si le test échoue, l'ensemble du pipeline sera considéré comme en échec et ne s'exécutera pas. Ajoutez le code ci-dessous sous le job de test :

        package:
    stage: package
    script: cat compiled.txt | gzip > packaged.gz
    artifacts:
      paths:
        - packaged.gz

    

        stages:          # List of stages for jobs, and their order of execution
    - build
    - test
    - package

  build-job:
    stage: build
    script:
      - echo "Hello " | tr -d "\n" > file1.txt
      - echo "world" > file2.txt
      - cat file1.txt file2.txt > compiled.txt
    artifacts:
      paths:
        - compiled.txt

  test:
    stage: test
    script: cat compiled.txt | grep -q 'Hello world'

  package:
    stage: package
    script: cat compiled.txt | gzip > packaged.gz
    artifacts:
      paths:
        - packaged.gz

    

Vous trouverez un lien vers le fichier de configuration dans notre exemple de projet.

Félicitations ! Vous venez de créer votre premier pipeline CI.

Pour activer l'intégration continue (CI) au sein de notre projet, nous devons effectuer un push du fichier .gitlab-ci.yml vers le dépôt. Une fois ce fichier situé à la racine du dépôt, chaque commit effectué au sein du projet lancera automatiquement un pipeline CI. Le pipeline initial s'exécutera immédiatement après avoir effectué un push de ce fichier vers le serveur.

• Cliquez sur le bouton « Fusionner » situé sur le côté gauche de l'explorateur de fichiers.
• Écrivez un message de commit, par exemple « Ajout d'une configuration CI. »
• Cliquez sur Valider et pousser.
• Lorsque le message « Valider dans une nouvelle branche ? » apparaît, sélectionnez « Non, utiliser la branche principale actuelle ».
• Pour revenir à votre projet, cliquez sur le bouton Accéder au projet situé en bas à gauche.

Félicitations ! Votre projet a bien été configuré pour lancer automatiquement un pipeline CI à chaque commit de code.

Pendant que le pipeline est en cours d'exécution, vous pouvez surveiller son état dans l'onglet CI/CD. Cette fonctionnalité vous permet de suivre facilement la progression de vos jobs, y compris leur statut d'exécution (par exemple, s'ils ont démarré, s'ils ont été effectués avec succès ou s'ils ont échoué). Vous pouvez également consulter les données de sortie générées par vos scripts de jobs.

• Accédez au projet GitLab et consultez le menu de gauche.
• Cliquez sur CI/CD dans le menu, puis sur Pipelines.
• Sur la page Pipelines, cherchez le bouton Pipeline dans la colonne Statut et cliquez dessus pour ouvrir le graphe de pipeline.
• Cet outil vous permet de consulter les jobs et leurs statuts respectifs.
• Cliquez sur un job pour ouvrir la console de jobs et en afficher les détails. Vous pouvez y visualiser toutes les étapes exécutées par le runner.
• Accédez au job d'empaquetage depuis la console pour afficher les étapes qui ont été traitées par le runner.
• Le job d'empaquetage génère un artefact que vous pouvez télécharger en cliquant sur le bouton Téléchargement situé sur le côté droit.
• Ces différentes étapes vous permettent de suivre efficacement le statut du pipeline, d'inspecter les détails du job et de récupérer tous les artefacts ou empaquetages pertinents générés lors de l'exécution du pipeline.

Félicitations ! Vous venez d'exécuter votre premier pipeline avec succès. À ce stade, vous avez consulté les résultats et téléchargé l'artefact du job.

Nous allons modifier la valeur attendue dans le job de test pour que celui-ci et l'ensemble du pipeline échouent.

• Modifiez le job de test en remplaçant la phrase « Hello World » par « hello world » (en lettres minuscules).
• Validez les modifications de code et accédez au pipeline, comme à l'étape 4.
• En vérifiant le pipeline, vous constaterez que le job de test a échoué. De plus, le job d'empaquetage suivant n'a pas démarré et l'exécution du pipeline a échoué, comme prévu.

À l'étape 5, nous avons vu que l'échec du job a fait échouer l'ensemble du pipeline. Vous pouvez introduire une logique dans votre pipeline qui détermine quand un échec de job entraînera l'échec de l'ensemble du pipeline. Pour ce faire, procédez comme suit :

• Évaluez les conditions dans lesquelles vous souhaitez qu'un échec de job entraîne un échec du pipeline. Vous pouvez, par exemple, empêcher l'exécution d'un pipeline si un job échoue sur la branche principale ou par défaut, tout en tolérant les échecs sur les autres branches.
• Définissez les règles qui régissent le comportement d'échec. Vous pouvez utiliser des variables telles que $CI_COMMIT_BRANCH pour vérifier la branche actuelle et prendre des décisions en fonction de celle-ci.
• Définissez vos conditions et spécifiez si le job doit être marqué comme allow_failure: false ou allow_failure: true.

• Ajoutez des règles/conditions à votre job de test.
• Utilisez le mot-clé allow_failure défini sur true ou false en fonction de la branche.

        test:
    stage: test
    script: cat compiled.txt | grep -q 'Hello world'
    rules:
      - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
        allow_failure: false
      - if: $CI_COMMIT_BRANCH
        allow_failure: true

    

Pour simplifier la configuration du pipeline, vous pouvez tirer parti des templates de pipeline intégrés fournis par GitLab. Ceux-ci sont prédéfinis pour les cas d'utilisation courants, tels que les scans de sécurité et les déploiements sur AWS.

Pour utiliser les templates de pipeline intégrés, procédez comme suit :

• Parcourez les templates de pipeline proposés par GitLab pour divers scénarios (build, test et déploiement), disponibles sur cette page.
• Sélectionnez le template qui correspond à vos besoins.
• Incorporez le template dans la configuration de votre pipeline en y faisant référence dans votre fichier .gitlab-ci.yml. Pour ce faire, importez le template à l'aide du mot-clé include et précisez le chemin ou l'URL du fichier de template.

Dans ce guide, nous allons ajouter le scan Code Quality à notre configuration à l'aide du template Code-Quality.

Ajoutez le template Code-Quality à votre fichier .gitlab-ci.yml en ajoutant le code suivant sous le bloc d'étapes.

        include:
    - template: Jobs/Code-Quality.gitlab-ci.yml

    

Validez et effectuez un push de cette modification.

Vous remarquerez qu'un job Code Quality a été ajouté à votre pipeline. Le scanner Code Quality passera en revue chaque modification de code validée dans ce dépôt et signalera les problèmes de qualité à corriger. Ces informations clés vous aident à améliorer votre code source et à en optimiser les performances.

C'est tout ! En suivant ces étapes, vous devriez être en mesure de maîtriser les bases de GitLab CI et d'automatiser les processus de build et de test de votre projet.