Back to Gitlabhq

Tutoriel : Créer et exécuter votre premier pipeline CI/CD GitLab

doc-locale/fr-fr/ci/quick_start/_index.md

19.2.08.0 KB
Original Source

{{< details >}}

  • Édition : Gratuite, GitLab Premium, GitLab Ultimate
  • Offre : GitLab.com, GitLab Self-Managed, GitLab Dedicated

{{< /details >}}

Ce tutoriel vous montre comment configurer et exécuter votre premier pipeline CI/CD dans GitLab.

Si vous connaissez déjà les concepts de base du CI/CD, vous pouvez vous familiariser avec les mots-clés courants dans Tutoriel : Créer un pipeline complexe.

Prérequis {#prerequisites}

Avant de commencer, assurez-vous de disposer des éléments suivants :

  • Un projet dans GitLab pour lequel vous souhaitez utiliser le CI/CD.
  • Le rôle Maintainer ou Owner pour le projet.

Si vous n'avez pas de projet, vous pouvez créer un projet public gratuitement sur https://gitlab.com.

Étapes {#steps}

Pour créer et exécuter votre premier pipeline :

  1. Vérifiez que vous disposez de runners pour exécuter vos jobs.

    Si vous utilisez GitLab.com, vous pouvez ignorer cette étape. GitLab.com met à votre disposition des runners d'instance.

  2. Créez un fichier .gitlab-ci.yml à la racine de votre dépôt. Ce fichier est l'endroit où vous définissez les jobs CI/CD.

Lorsque vous commitez le fichier dans votre dépôt, le runner exécute vos jobs. Les résultats des jobs sont affichés dans un pipeline.

Vérifiez que vous disposez de runners {#ensure-you-have-runners-available}

Dans GitLab, les runners sont des agents qui exécutent vos jobs CI/CD.

Si vous utilisez GitLab.com, vous pouvez ignorer cette étape. GitLab.com met à votre disposition des runners d'instance.

Pour afficher les runners disponibles :

  1. Dans la barre supérieure, sélectionnez Rechercher ou aller à et trouvez votre projet.
  2. Dans la barre latérale gauche, sélectionnez Paramètres > CI/CD.
  3. Développez Runners.

Tant que vous disposez d'au moins un runner actif, avec un cercle vert à côté de lui, vous avez un runner disponible pour traiter vos jobs.

Si vous n'avez pas accès à ces paramètres, contactez votre administrateur GitLab.

Si vous ne disposez pas d'un runner {#if-you-dont-have-a-runner}

Si vous ne disposez pas d'un runner :

  1. Installez GitLab Runner sur votre machine locale.
  2. Enregistrez le runner pour votre projet. Choisissez l'exécuteur shell.

Lorsque vos jobs CI/CD s'exécutent, lors d'une étape ultérieure, ils s'exécuteront sur votre machine locale.

Créer un fichier .gitlab-ci.yml {#create-a-gitlab-ciyml-file}

Créez maintenant un fichier .gitlab-ci.yml. Il s'agit d'un fichier YAML dans lequel vous spécifiez des instructions pour GitLab CI/CD.

Dans ce fichier, vous définissez :

  • La structure et l'ordre des jobs que le runner doit exécuter.
  • Les décisions que le runner doit prendre lorsque des conditions spécifiques sont rencontrées.

Pour créer un fichier .gitlab-ci.yml dans votre projet :

  1. Dans la barre supérieure, sélectionnez Rechercher ou aller à et trouvez votre projet.

  2. Dans la barre latérale gauche, sélectionnez Code > Dépôt.

  3. Au-dessus de la liste de fichiers, sélectionnez la branche vers laquelle vous souhaitez commiter. Si vous n'êtes pas sûr(e), conservez master ou main. Ensuite, dans le coin supérieur droit, sélectionnez l'icône plus ({{< icon name="plus" >}}) et Nouveau fichier :

  4. Pour le Nom du fichier, saisissez .gitlab-ci.yml et dans la zone de texte plus grande, collez cet exemple de code :

    yaml
    build-job:
      stage: build
      script:
        - echo "Hello, $GITLAB_USER_LOGIN!"
    
    test-job1:
      stage: test
      script:
        - echo "This job tests something"
    
    test-job2:
      stage: test
      script:
        - echo "This job tests something, but takes more time than test-job1."
        - echo "After the echo commands complete, it runs the sleep command for 20 seconds"
        - echo "which simulates a test that runs 20 seconds longer than test-job1"
        - sleep 20
    
    deploy-prod:
      stage: deploy
      script:
        - echo "This job deploys something from the $CI_COMMIT_BRANCH branch."
      environment: production
    

    Cet exemple montre quatre jobs : build-job, test-job1, test-job2 et deploy-prod. Les commentaires figurant dans les commandes echo s'affichent dans l'interface lorsque vous consultez les jobs. Les valeurs des variables prédéfinies $GITLAB_USER_LOGIN et $CI_COMMIT_BRANCH sont renseignées lors de l'exécution des jobs.

  5. Sélectionnez Valider les modifications.

Le pipeline démarre et exécute les jobs que vous avez définis dans le fichier .gitlab-ci.yml.

Afficher le statut de votre pipeline et de vos jobs {#view-the-status-of-your-pipeline-and-jobs}

Examinez maintenant votre pipeline et les jobs qu'il contient.

  1. Accédez à Version > Pipelines. Un pipeline avec trois étapes devrait s'afficher :

  2. Affichez une représentation visuelle de votre pipeline en sélectionnant l'ID du pipeline (#676 dans cet exemple) :

  3. Affichez les détails d'un job en sélectionnant le nom du job. Par exemple, deploy-prod :

Vous avez créé avec succès votre premier pipeline CI/CD dans GitLab. Félicitations !

Vous pouvez maintenant commencer à personnaliser votre fichier .gitlab-ci.yml et à définir des jobs plus avancés.

Conseils pour .gitlab-ci.yml {#gitlab-ciyml-tips}

Voici quelques conseils pour commencer à travailler avec le fichier .gitlab-ci.yml.

Pour la syntaxe complète de .gitlab-ci.yml, consultez la référence complète de la syntaxe YAML CI/CD.

  • Utilisez l'éditeur de pipeline pour modifier votre fichier .gitlab-ci.yml.
  • Chaque job contient une section script et appartient à une étape :
  • Vous pouvez définir une configuration supplémentaire pour personnaliser le comportement de vos jobs et de vos étapes :
    • Utilisez le mot-clé rules pour spécifier quand exécuter ou ignorer des jobs. Les mots-clés hérités only et except sont toujours pris en charge, mais ne peuvent pas être utilisés avec rules dans le même job.
    • Conservez les informations persistantes entre les jobs et les étapes dans un pipeline avec cache et artifacts. Ces mots-clés permettent de stocker les dépendances et la sortie des jobs, même lors de l'utilisation de runners éphémères pour chaque job.
    • Utilisez le mot-clé default pour spécifier des configurations supplémentaires appliquées à tous les jobs. Ce mot-clé est souvent utilisé pour définir les sections before_script et after_script qui doivent s'exécuter sur chaque job.

Migrer depuis :