doc-locale/fr-fr/ci/pipelines/_index.md
{{< details >}}
{{< /details >}}
Les pipelines CI/CD sont le composant fondamental de GitLab CI/CD. Les pipelines sont configurés dans un fichier .gitlab-ci.yml à l'aide de mots-clés YAML.
Les pipelines peuvent s'exécuter automatiquement pour des événements spécifiques, comme lors d'un push vers une branche, de la création d'une merge request, ou selon une planification. Si nécessaire, vous pouvez également exécuter des pipelines manuellement.
Les pipelines sont composés de :
Un pipeline simple peut se composer de trois étapes, exécutées dans l'ordre suivant :
build, avec un job appelé compile qui compile le code du projet.test, avec deux jobs appelés test1 et test2 qui exécutent divers tests sur le code. Ces tests ne s'exécuteraient que si le job compile s'est terminé avec succès.deploy, avec un job appelé deploy-to-production. Ce job ne s'exécuterait que si les deux jobs de l'étape test ont démarré et se sont terminés avec succès.Pour commencer avec votre premier pipeline, consultez Créer et exécuter votre premier pipeline GitLab CI/CD.
Les pipelines peuvent être configurés de nombreuses façons différentes :
needs s'exécutent en fonction des dépendances entre les jobs et peuvent s'exécuter plus rapidement que les pipelines de base.Les pipelines et leurs jobs et étapes composants sont définis avec des mots-clés YAML dans le fichier de configuration du pipeline CI/CD de chaque projet. Lors de la modification de la configuration CI/CD dans GitLab, vous devez utiliser l'éditeur de pipeline.
Vous pouvez également configurer des aspects spécifiques de vos pipelines via l'interface utilisateur GitLab :
Si vous utilisez VS Code pour modifier votre configuration GitLab CI/CD, l'extension GitLab pour VS Code vous aide à valider votre configuration et à visualiser le statut de votre pipeline.
{{< history >}}
ci_inputs_for_pipelines. Activé par défaut.ci_inputs_for_pipelines a été supprimé.{{< /history >}}
Les pipelines peuvent être exécutés manuellement, avec des variables prédéfinies ou spécifiées manuellement.
Vous pouvez le faire si les résultats d'un pipeline (par exemple, une compilation de code) sont requis en dehors du fonctionnement standard du pipeline.
Pour exécuter un pipeline manuellement :
Le pipeline exécute désormais les jobs tels qu'ils sont configurés.
{{< history >}}
ci_show_manual_variables_in_pipeline. Désactivé par défaut.ci_show_manual_variables_in_pipeline a été supprimé.{{< /history >}}
Vous pouvez voir toutes les variables spécifiées lors de l'exécution manuelle du pipeline.
Prérequis :
Le rôle requis dépend de ce que vous souhaitez faire :
| Action | Rôle minimum |
|---|---|
| Afficher les noms des variables | Invité |
| Afficher les valeurs des variables | Développeur |
| Configurer le paramètre de visibilité | Propriétaire |
[!warning] Lorsque vous activez ce paramètre, les utilisateurs disposant du rôle Développeur peuvent consulter les valeurs de variables susceptibles de contenir des informations sensibles issues de n'importe quelle exécution manuelle de pipeline. Pour les données sensibles telles que les identifiants ou les jetons, utilisez des variables protégées ou la gestion des secrets externe plutôt que des variables de pipeline manuel.
Pour afficher les variables de pipeline manuel :
Les valeurs des variables sont masquées par défaut. Si vous disposez du rôle Développeur, Mainteneur ou Propriétaire, vous pouvez sélectionner l'icône en forme d'œil pour afficher les valeurs.
{{< history >}}
{{< /history >}}
Vous pouvez utiliser les mots-clés description et value pour définir des variables au niveau du pipeline (globales) qui sont préremplies lors de l'exécution manuelle d'un pipeline. Utilisez la description pour expliquer des informations telles que l'utilisation de la variable et les valeurs acceptables. Vous pouvez utiliser Markdown dans la description.
Les variables au niveau du job ne peuvent pas être préremplies.
Dans les pipelines déclenchés manuellement, la page Nouveau pipeline affiche toutes les variables au niveau du pipeline qui ont une description définie dans le fichier .gitlab-ci.yml. La description s'affiche sous la variable.
Vous pouvez modifier la valeur préremplie, ce qui remplace la valeur pour cette seule exécution de pipeline. Toutes les variables remplacées par ce processus sont développées et non masquées. Si vous ne définissez pas de value pour la variable dans le fichier de configuration, le nom de la variable reste affiché, mais le champ de valeur est vide.
Par exemple :
variables:
DEPLOY_CREDENTIALS:
description: "The deployment credentials."
DEPLOY_ENVIRONMENT:
description: "Select the deployment target. Valid options are: 'canary', 'staging', 'production', or a stable branch of your choice."
value: "canary"
Dans cet exemple :
DEPLOY_CREDENTIALS est répertorié sur la page Nouveau pipeline, mais sans valeur définie. L'utilisateur est censé définir la valeur à chaque exécution manuelle du pipeline.DEPLOY_ENVIRONMENT est prérempli sur la page Nouveau pipeline avec canary comme valeur par défaut, et le message explique les autres options.[!note] En raison d'un problème connu, les projets qui utilisent des pipelines de conformité peuvent avoir des variables préremplies qui n'apparaissent pas lors de l'exécution manuelle d'un pipeline. Pour contourner ce problème, modifiez la configuration du pipeline de conformité.
Vous pouvez définir un tableau de valeurs de variables CI/CD parmi lesquelles l'utilisateur peut choisir lors de l'exécution manuelle d'un pipeline. Ces valeurs figurent dans une liste déroulante sur la page Nouveau pipeline. Ajoutez la liste des options de valeurs à options et définissez la valeur par défaut avec value. La chaîne dans value doit également être incluse dans la liste options.
Par exemple :
variables:
DEPLOY_ENVIRONMENT:
value: "staging"
options:
- "production"
- "staging"
- "canary"
description: "The deployment target. Set to 'staging' by default."
Vous pouvez utiliser une chaîne de requête pour préremplir la page Nouveau pipeline. Par exemple, la chaîne de requête .../pipelines/new?ref=my_branch&var[foo]=bar&file_var[file_foo]=file_bar préremplie la page Nouveau pipeline avec :
my_branch.foobarfile_foofile_barLe format de l'URL pipelines/new est :
.../pipelines/new?ref=<branch>&var[<variable_key>]=<value>&file_var[<file_key>]=<value>
Les paramètres suivants sont pris en charge :
ref : spécifier la branche pour remplir le champ Run for.var : spécifier une variable Variable.file_var : spécifier une variable File.Pour chaque var ou file_var, une clé et une valeur sont requises.
Les jobs manuels vous permettent d'exiger une interaction manuelle avant de poursuivre l'exécution du pipeline.
Vous pouvez le faire directement depuis le graphe de pipeline. Sélectionnez Exécution ({{< icon name="play" >}}) pour exécuter ce job particulier.
Par exemple, votre pipeline peut démarrer automatiquement, mais nécessiter une action manuelle pour déployer en production. Dans l'exemple suivant, l'étape production comporte un job avec une action manuelle :
Si une étape ne contient que des jobs manuels, vous pouvez démarrer tous les jobs en même temps en sélectionnant Exécuter tout manuellement ({{< icon name="play" >}}) au-dessus de l'étape. Si l'étape contient des jobs non manuels, l'option n'est pas affichée.
Pour pousser un commit sans déclencher un pipeline, ajoutez [ci skip] ou [skip ci], avec n'importe quelle casse, dans votre message de commit.
Vous pouvez aussi, avec Git 2.10 ou une version ultérieure, utiliser l'option Git push ci.skip. L'option push ci.skip n'ignore pas les pipelines de merge request.
Lorsque vous ignorez un pipeline :
skipped dans l'API.[!note] Les politiques d'exécution de pipeline et les politiques d'exécution de scan peuvent restreindre ou désactiver la directive
[skip ci]. Pour plus d'informations, consultez la page suivante :
- Le type
skip_cidans les politiques d'exécution de pipeline.- Le type
skip_cidans les politiques d'exécution de scan.
Les utilisateurs disposant du rôle Propriétaire pour un projet peuvent supprimer un pipeline :
#123456789) ou l'icône de statut du pipeline (par exemple Réussi) du pipeline à supprimer.La suppression d'un pipeline ne supprime pas automatiquement ses pipelines enfants. Consultez le ticket 39503 pour plus de détails.
[!warning] La suppression d'un pipeline expire tous les caches du pipeline et supprime tous les objets directement associés, tels que les jobs, les logs, les artefacts et les déclencheurs. This action cannot be undone.
Un modèle de sécurité strict est appliqué lorsque des pipelines sont exécutés sur des branches protégées.
Les actions suivantes sont autorisées sur les branches protégées si l'utilisateur est autorisé à fusionner ou à pousser vers cette branche spécifique :
Les Variables marquées comme protégées sont accessibles aux jobs qui s'exécutent dans les pipelines des branches protégées. N'accordez aux utilisateurs le droit de fusionner vers des branches protégées que s'ils ont l'autorisation d'accéder à des informations sensibles telles que les identifiants de déploiement et les jetons.
Les Runners marqués comme protégées peuvent exécuter des jobs uniquement sur des branches protégées, empêchant l'exécution de code non fiable sur le runner protégé et évitant l'accès involontaire aux clés de déploiement et autres identifiants. Pour s'assurer que les jobs destinés à être exécutés sur des runners protégés n'utilisent pas de runners standard, ils doivent être étiquetés en conséquence.
Consultez le fonctionnement de l'accès aux variables et aux runners protégés dans le contexte des pipelines de merge request.
Consultez la page sur la sécurité des déploiements pour des recommandations de sécurité supplémentaires concernant la sécurisation de vos pipelines.
{{< details >}}
{{< /details >}}
Vous pouvez configurer votre projet pour déclencher automatiquement un pipeline en fonction des étiquettes d'un autre projet. Lorsqu'un nouveau pipeline d'étiquette dans le projet abonné se termine, il déclenche un pipeline sur la branche par défaut de votre projet, indépendamment du succès, de l'échec ou de l'annulation du pipeline d'étiquette.
Vous pouvez aussi utiliser des jobs CI/CD avec des jetons de déclenchement de pipeline pour déclencher des pipelines lorsqu'un autre pipeline s'exécute. Cette méthode est plus fiable et flexible que les abonnements aux pipelines et constitue l'approche recommandée.
Prérequis :
Pour déclencher le pipeline lors de la reconstruction du projet upstream :
<namespace>/<project>. Par exemple, si le projet est https://gitlab.com/gitlab-org/gitlab, utilisez gitlab-org/gitlab.Le nombre maximum d'abonnements aux pipelines upstream est de 2 par défaut, pour les projets upstream et downstream. Sur GitLab Self-Managed, un administrateur peut modifier cette limite.
Le temps d'exécution total d'un pipeline donné exclut :
Cela signifie que si un job est relancé ou réexécuté manuellement, seule la durée de la dernière exécution est incluse dans le temps d'exécution total.
Chaque job est représenté sous la forme d'une Period, qui se compose de :
Period#first (lorsque le job a démarré).Period#last (lorsque le job s'est terminé).Un exemple simple est :
Dans l'exemple :
Visuellement, on peut le représenter comme suit :
0 1 2 3 4 5 6 7
AAAAAAA
BBBBBBB
A'A'A'A
CCCC
Comme A est relancé, il est ignoré, et seul le job A' est comptabilisé. L'union de B, A' et C est (1, 4) et (6, 7). Par conséquent, le temps d'exécution total est :
(4 - 1) + (7 - 6) => 4
Pour afficher tous les pipelines qui se sont exécutés pour votre projet :
Vous pouvez filtrer la page Pipelines par :
Sélectionnez ID du pipeline dans la liste déroulante en haut à droite pour afficher les ID des pipelines (ID unique à l'échelle de l'instance). Sélectionnez pipeline IID pour afficher les IID des pipelines (ID interne, unique à l'échelle du projet uniquement).
Pour afficher les pipelines liés à une merge request spécifique, accédez à l'onglet Pipelines dans la merge request.
Sélectionnez un pipeline pour ouvrir la page de détails du pipeline, qui affiche chaque job du pipeline. Depuis cette page, vous pouvez annuler un pipeline en cours d'exécution, relancer des jobs échoués ou supprimer un pipeline.
La page de détails du pipeline affiche un graphe de tous les jobs du pipeline :
Vous pouvez utiliser une URL standard pour accéder aux détails de pipelines spécifiques :
gitlab.example.com/my-group/my-project/-/pipelines/latest : La page de détails du dernier pipeline pour le commit le plus récent sur la branche par défaut du projet.gitlab.example.com/my-group/my-project/-/pipelines/<branch>/latest : La page de détails du dernier pipeline pour le commit le plus récent sur la branche <branch> du projet.needs {#group-jobs-by-stage-or-needs-configuration}Lorsque vous configurez des jobs avec le mot-clé needs, vous disposez de deux options pour grouper les jobs dans la page de détails du pipeline. Pour grouper les jobs par configuration d'étape, sélectionnez stage dans la section Grouper les jobs par :
Pour grouper les jobs par configuration needs, sélectionnez Dépendances des jobs. Vous pouvez éventuellement sélectionner Afficher les dépendances pour afficher des lignes entre les jobs dépendants.
Les jobs de la colonne la plus à gauche s'exécutent en premier, et les jobs qui en dépendent sont regroupés dans les colonnes suivantes. Dans cet exemple :
lint-job est configuré avec needs: [] et ne dépend d'aucun job, il s'affiche donc dans la première colonne, bien qu'il se trouve dans l'étape test.test-job1 dépend de build-job1, et test-job2 dépend à la fois de build-job1 et de build-job2, de sorte que les deux jobs de test s'affichent dans la deuxième colonne.deploy dépendent des jobs de la deuxième colonne (qui eux-mêmes dépendent d'autres jobs antérieurs), de sorte que les jobs de déploiement s'affichent dans la troisième colonne.Lorsque vous survolez un job dans la vue Dépendances des jobs, chaque job devant s'exécuter avant le job sélectionné est mis en surbrillance :
Les mini-graphes de pipeline prennent moins de place et permettent de voir en un coup d'œil si tous les jobs ont réussi ou si quelque chose a échoué. Ils affichent tous les jobs associés à un seul commit et le résultat net de chaque étape de votre pipeline. Vous pouvez rapidement identifier ce qui a échoué et le corriger.
Le mini-graphe de pipeline regroupe toujours les jobs par étape et s'affiche dans toute l'interface GitLab lors de l'affichage des détails du pipeline ou du commit.
Les étapes dans les mini-graphes de pipeline sont extensibles. Survolez chaque étape pour voir son nom et son statut, puis sélectionnez une étape pour développer la liste de ses jobs.
Lorsqu'un pipeline contient un job qui déclenche un pipeline downstream, vous pouvez voir le pipeline downstream dans la vue de détails du pipeline et dans les mini-graphes.
Dans la vue de détails du pipeline, une carte s'affiche pour chaque pipeline downstream déclenché, à droite du graphe de pipeline. Survolez une carte pour voir quel job a déclenché le pipeline downstream. Sélectionnez une carte pour afficher le pipeline downstream à droite du graphe de pipeline.
Dans le mini-graphe de pipeline, le statut de chaque pipeline downstream déclenché s'affiche sous forme d'icônes de statut supplémentaires à droite du mini-graphe. Sélectionnez l'icône de statut d'un pipeline downstream pour accéder à la page de détails de ce pipeline downstream.
Les données d'analyse des pipelines sont disponibles sur la page Données d'analyse CI/CD.
Les badges de statut du pipeline et de rapport de couverture des tests sont disponibles et configurables pour chaque projet. Pour obtenir des informations sur l'ajout de badges de pipeline aux projets, consultez Badges de pipeline.
GitLab fournit des points de terminaison API pour :
Lorsqu'un runner prend en charge un job de pipeline, GitLab fournit les métadonnées de ce job. Cela inclut les refspecs Git, qui indiquent quelle référence (telle qu'une branche ou une étiquette) et quel commit (SHA1) sont extraits de votre dépôt de projet.
Ce tableau répertorie les refspecs injectées pour chaque type de pipeline :
| Type de pipeline | Refspecs |
|---|---|
| pipeline pour les branches | +<sha>:refs/pipelines/<id> et +refs/heads/<name>:refs/remotes/origin/<name> |
| pipeline pour les étiquettes | +<sha>:refs/pipelines/<id> et +refs/tags/<name>:refs/tags/<name> |
| pipeline de merge request | +refs/pipelines/<id>:refs/pipelines/<id> |
| pipeline pour les références de charge de travail | +refs/pipelines/<id>:refs/pipelines/<id> |
Les références refs/heads/<name> et refs/tags/<name> existent dans votre dépôt de projet. GitLab génère la référence spéciale refs/pipelines/<id> pendant l'exécution d'un job de pipeline. Cette référence peut être créée même après la suppression de la branche ou de l'étiquette associée. Elle est donc utile dans certaines fonctionnalités telles que l'arrêt automatique d'un environnement et les merge trains qui peuvent exécuter des pipelines après la suppression d'une branche.
Lorsqu'un utilisateur supprime son compte GitLab.com, la suppression n'intervient pas avant sept jours. Pendant cette période, tout abonnement aux pipelines créé par cet utilisateur continue à s'exécuter avec les autorisations initiales de l'utilisateur. Pour éviter des exécutions de pipeline non autorisées, mettez immédiatement à jour les paramètres d'abonnement aux pipelines pour l'utilisateur supprimé.
Si les variables prédéfinies d'un pipeline sont définies dans un fichier séparé, elles peuvent ne pas s'afficher sur la page New Pipeline. Vous devez avoir l'autorisation d'accéder au fichier séparé, faute de quoi les variables prédéfinies ne peuvent pas être affichées.