Démarrage rapide pour l'intégration continue GitLab

Dans un projet, divers composants tels que votre base de code, la configuration CI, la planification, les analyses et les membres de l'équipe sont gérés. Dans ce guide, nous créerons un nouveau projet vierge, ne contenant qu'un fichier readme.

• Créez un nouveau projet en cliquant sur l'icône plus à droite de la barre supérieure, et sélectionnez Nouveau projet/dépôt
• Sélectionnez Créer un projet vierge. Sous Nom du projet tapez mon-projet.
• Cliquez sur Créer le projet.
• Félicitations ! vous avez créé avec succès votre premier projet.

Dans GitLab, la configuration CI est définie en code en utilisant la syntaxe YAML. Cette configuration spécifie les instructions à la machine runner concernant l'exécution des tâches, l'ordre des tâches, les conditions des tâches, et plus encore. Pour définir la configuration CI, vous devez créer un fichier appelé .gitlab-ci.yml, qui doit être situé à la racine de votre dépôt. Dans ce guide, nous utiliserons l'IDE Web pour créer et modifier ce fichier.

Pour accéder à l'IDE Web, cliquez simplement sur le bouton rapide IDE Web situé dans votre projet. Une fois dans l'IDE Web, naviguez vers 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 le fichier nouvellement créé .gitlab-ci.yml.

L'ordre d'exécution des tâches est déterminé par les étapes définies dans la configuration. Dans ce guide, nous définirons trois étapes : build, test et package, dans cet ordre spécifique. Copiez et collez le code suivant dans le fichier .gitlab-ci.yml :

  stages:
    - build
    - test
    - package

Imaginez un scénario où vous êtes chargé de créer deux fichiers texte. Il est de la plus haute importance que la concaténation de ces fichiers inclue la phrase « Hello world. » Notre objectif est de construire, tester et empaqueter cette exigence en utilisant les tâches du pipeline.

Nous spécifierons une tâche de construction qui accomplit les tâches suivantes : créer un fichier texte avec le mot « Hello, » créer un autre fichier texte avec le mot « World, » et générer un troisième fichier qui stocke le contenu combiné des deux fichiers. Nous sauvegarderons le troisième fichier comme artefact, afin que les tâches suivantes dans les étapes de test et d'empaquetage puissent y accéder. Veuillez insérer le code fourni sous le bloc des é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 construction, nous incorporerons une tâche de test. Cette tâche examinera si le fichier compiled.txt contient effectivement la phrase attendue « Hello world ». Veuillez insérer le code suivant sous la tâche de construction :

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

Après la réussite du test, notre prochain objectif est de générer un package pour notre code. Pour accomplir cela, nous inclurons une tâche d'empaquetage. Il est important de noter que si le test échoue, l'ensemble du pipeline sera considéré comme non réussi et ne procédera pas. Veuillez insérer le code fourni sous la tâche de test :

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

  stages:          # Liste des étapes pour les tâches, et leur ordre d'exécution
    - 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

Voici un lien vers le fichier de configuration dans notre projet d'exemple.

Félicitations !! vous avez construit votre premier pipeline CI.

Pour activer l'intégration continue (CI) dans notre projet, nous devons pousser le fichier .gitlab-ci.yml vers le dépôt. Une fois ce fichier situé à la racine du dépôt, chaque commit effectué sur le projet initiera automatiquement un pipeline CI. Le pipeline initial commencera immédiatement après avoir poussé ce fichier vers le serveur.

• Cliquez sur l'icône Fusionner située à gauche de l'explorateur de fichiers.
• Fournissez un message de commit tel que « Ajout de la configuration CI. »
• Cliquez sur Valider et pousser.
• Lorsque vous êtes invité avec « Valider vers une nouvelle branche ? » sélectionnez « Non, utiliser la branche actuelle main ».
• Pour retourner à votre projet, cliquez sur le bouton Aller au projet situé en bas à gauche.

Félicitations ! Votre projet est maintenant configuré avec succès pour initier automatiquement un pipeline CI pour chaque commit de code.

Pendant que le pipeline s'exécute, vous pouvez surveiller son statut dans l'onglet CI/CD. Cette fonctionnalité vous permet de suivre facilement le progrès de vos tâches, y compris leur statut d'exécution (comme si elles ont commencé, réussi, échoué, etc.), ainsi que toute sortie générée par vos scripts de tâche.

• Naviguez vers le projet GitLab et localisez le menu de gauche.
• Cliquez sur CI/CD dans le menu, cliquez sur Pipelines.
• Sur la page Pipelines, localisez le bouton du pipeline dans la colonne Statut. Cliquez dessus pour ouvrir le graphique du pipeline.
• Maintenant, vous pouvez observer les tâches et leurs statuts respectifs dans le graphique du pipeline.
• Pour explorer une tâche spécifique, cliquez dessus pour ouvrir la console de la tâche. Cette console affiche toutes les étapes exécutées sur la machine Runner.
• Ouvrez la console de la tâche d'empaquetage pour voir les étapes qui ont été traitées par le runner.
• La tâche d'empaquetage génère un artefact, vous pouvez le télécharger en cliquant sur le bouton télécharger situé sur le côté droit.
• En suivant ces étapes, vous pouvez efficacement suivre le statut du pipeline, inspecter les détails des tâches et récupérer tous les artefacts ou packages pertinents produits pendant l'exécution du pipeline.

Félicitations pour avoir exécuté avec succès votre premier pipeline. Le pipeline a réussi ! Vous avez maintenant vu les résultats et téléchargé l'artefact de la tâche.

Nous changerons la valeur attendue dans la tâche de test, la tâche de test échouera ainsi que l'ensemble du pipeline échouera.

• Modifiez la tâche test en modifiant la phrase « Hello World » en « hello world » (avec des lettres minuscules).
• Validez les changements de code et procédez à la visualisation du pipeline, similaire à l'étape 4.
• En inspectant le pipeline, vous observerez que la tâche de test a échoué. De plus, la tâche package suivante n'a pas commencé, et le pipeline lui-même a échoué comme attendu.

À l'étape 5, nous avons vu que l'échec d'une tâche a fait échouer l'ensemble du pipeline. Vous pouvez introduire une logique dans votre pipeline qui détermine quand un échec de tâche causera l'échec de l'ensemble du pipeline avec les étapes suivantes :

• Évaluez les conditions sous lesquelles vous voulez qu'un échec de tâche résulte en un échec de pipeline. Par exemple, vous pourriez vouloir imposer un échec de pipeline si une tâche échoue sur la branche principale ou par défaut, tout en permettant aux échecs de tâches sur d'autres branches de procéder avec le pipeline.
• Définissez des règles qui gouvernent le comportement d'échec. Vous pouvez exploiter des variables telles que $CI_COMMIT_BRANCH pour vérifier la branche actuelle et prendre des décisions basées sur celle-ci.
• Définissez les conditions appropriées et spécifiez si la tâche doit être marquée comme allow_failure: false ou allow_failure: true.

• Ajoutez des conditions rules/if à votre tâche de test.
• Utilisez le mot-clé allow_failure défini sur true ou false basé sur 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 rationaliser la configuration du pipeline, vous pouvez exploiter les modèles de pipeline intégrés fournis par GitLab. Ces modèles offrent des configurations prédéfinies pour des cas d'usage courants, tels que les scans de sécurité, les déploiements AWS, etc.

Suivez ces étapes pour utiliser les modèles de pipeline intégrés :

• Explorez les modèles de pipeline disponibles offerts par GitLab pour divers scénarios tels que la construction, les tests, le déploiement, et plus encore. Ces modèles peuvent être trouvés ici.
• Sélectionnez le modèle qui s'aligne avec vos exigences.
• Incorporez le modèle dans votre configuration de pipeline en le référençant dans votre fichier .gitlab-ci.yml. Vous pouvez généralement faire cela en important le modèle en utilisant le mot-clé include et en spécifiant le chemin ou l'URL vers le fichier de modèle.

Dans ce guide, nous ajouterons un scan de qualité de code à notre configuration en utilisant le modèle Code-Quality.

Incluez le modèle de qualité de code à votre .gitlab-ci.yml en ajoutant ce code sous le bloc des étapes.

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

Validez et poussez ce changement.

Vous remarquerez qu'une tâche de qualité de code a été ajoutée à votre pipeline. Le scanner de qualité de code analysera minutieusement tous les changements de code validés dans ce dépôt, et fournira des commentaires précieux, mettant en évidence tous les problèmes de qualité de code qui nécessitent attention et amélioration. Cette perspicacité précieuse vous permet d'améliorer la qualité globale de votre base de code et d'optimiser ses performances.

C'est tout ! Avec ces étapes, vous devriez pouvoir commencer avec GitLab CI et automatiser les processus de construction et de test de votre projet.