doc-locale/fr-fr/ci/pipelines/settings.md
{{< details >}}
{{< /details >}}
Vous pouvez personnaliser la façon dont les pipelines s'exécutent pour votre projet.
Pour les projets publics et internes, vous pouvez modifier qui peut voir vos :
Pour modifier la visibilité de vos pipelines et des fonctionnalités associées :
Dans la barre supérieure, sélectionnez Rechercher ou aller à et trouvez votre projet.
Dans la barre latérale gauche, sélectionnez Paramètres > CI/CD.
Développez Pipelines généraux.
Cochez ou décochez la case Visibilité du pipeline basée sur les projets. Lorsqu'elle est cochée, les pipelines et les fonctionnalités associées sont visibles :
Lorsqu'elle est décochée :
Vous pouvez contrôler la visibilité des pipelines pour les non-membres du projet dans les projets publics.
Ce paramètre n'a aucun effet lorsque :
Pour modifier la visibilité des pipelines pour les non-membres du projet :
Le tableau des autorisations CI/CD répertorie les fonctionnalités de pipeline auxquelles les non-membres du projet peuvent accéder lorsque Toute personne ayant accès est sélectionné.
Vous pouvez configurer l'annulation automatique des pipelines en attente ou en cours d'exécution lorsqu'un pipeline pour de nouvelles modifications s'exécute sur la même branche. Vous pouvez activer cette option dans les paramètres du projet :
Utilisez le mot-clé interruptible pour indiquer si un job en cours d'exécution peut être annulé avant la fin de son exécution. Une fois qu'un job avec interruptible: false démarre, l'ensemble du pipeline n'est plus considéré comme interruptible.
Votre projet peut avoir plusieurs jobs de déploiement simultanés planifiés pour s'exécuter dans le même délai.
Cela peut conduire à une situation où un ancien job de déploiement s'exécute après un plus récent, ce qui n'est peut-être pas ce que vous souhaitez.
Pour éviter ce scénario :
Pour plus d'informations, consultez Sécurité du déploiement.
{{< details >}}
{{< /details >}}
Vous pouvez personnaliser les rôles autorisés à annuler des pipelines ou des jobs.
Par défaut, les utilisateurs disposant du rôle Developer, Maintainer ou Owner peuvent annuler des pipelines ou des jobs. Vous pouvez restreindre l'autorisation d'annulation aux seuls utilisateurs disposant du rôle Maintainer ou Owner, ou empêcher complètement l'annulation de tout pipeline ou job.
Pour modifier les autorisations d'annulation des pipelines ou des jobs :
GitLab s'attend à trouver le fichier de configuration CI/CD (.gitlab-ci.yml) dans le répertoire racine du projet. Cependant, vous pouvez spécifier un autre chemin de nom de fichier, y compris des emplacements extérieurs au projet.
Pour personnaliser le chemin :
[!note] Vous ne pouvez pas utiliser l'éditeur de pipeline de votre projet pour modifier des fichiers de configuration CI/CD dans d'autres projets ou sur un site externe.
Si le fichier de configuration CI/CD ne se trouve pas dans le répertoire racine, le chemin doit être relatif à celui-ci. Par exemple :
my/path/.gitlab-ci.ymlmy/path/.my-custom-file.ymlSi le fichier de configuration CI/CD se trouve sur un site externe, l'URL doit se terminer par .yml :
http://example.com/generate/ci/config.ymlSi le fichier de configuration CI/CD se trouve dans un projet différent :
@ et du chemin complet du groupe et du projet.Par exemple :
.gitlab-ci.yml@namespace/another-projectmy/path/.my-custom-file.yml@namespace/subgroup/another-projectmy/path/.my-custom-file.yml@namespace/subgroup1/subgroup2/another-project:refnameSi le fichier de configuration se trouve dans un projet distinct, vous pouvez définir des autorisations plus granulaires. Par exemple :
Les autres utilisateurs et projets peuvent alors accéder au fichier de configuration sans pouvoir le modifier.
Vous pouvez choisir la façon dont votre dépôt est récupéré depuis GitLab lors de l'exécution d'un job.
git clone est plus lent car il clone le dépôt depuis le début pour chaque job. Cependant, la copie de travail locale est toujours intacte.git fetch est plus rapide car il réutilise la copie de travail locale (et revient au clone si elle n'existe pas). Cette option est recommandée, en particulier pour les grands dépôts.La stratégie Git configurée peut être remplacée par la variable GIT_STRATEGY dans le fichier .gitlab-ci.yml.
Vous pouvez limiter le nombre de modifications que GitLab CI/CD récupère lors du clonage d'un dépôt.
1000. Pour désactiver le clone superficiel et faire en sorte que GitLab CI/CD récupère toutes les branches et tous les tags à chaque fois, laissez la valeur vide ou définissez-la sur 0.Les projets nouvellement créés ont une valeur git depth par défaut de 20.
Cette valeur peut être remplacée par la variable GIT_DEPTH dans le fichier .gitlab-ci.yml.
Vous pouvez définir la durée pendant laquelle un job peut s'exécuter avant d'expirer.
2 hours. La durée doit être d'au moins 10 minutes et inférieure à un mois. La valeur par défaut est de 60 minutes. Les jobs en attente sont abandonnés après 24 heures d'inactivité.Les jobs qui dépassent le délai d'attente sont marqués comme ayant échoué.
Lorsqu'un délai d'attente de projet et un délai d'attente de runner sont tous deux définis, la valeur la plus faible est prioritaire.
Les jobs sans sortie pendant une heure sont abandonnés, quel que soit le délai d'attente. Pour éviter que cela se produise, ajoutez un script pour afficher en continu la progression. Pour plus d'informations, consultez le ticket 25359.
Vous pouvez utiliser des badges de pipeline pour indiquer le statut du pipeline et la couverture des tests de vos projets. Ces badges sont déterminés par le dernier pipeline réussi.
Les pipelines GitLab CI/CD sont activés par défaut sur tous les nouveaux projets. Si vous utilisez un serveur CI/CD externe comme Jenkins ou Drone CI, vous pouvez désactiver GitLab CI/CD pour éviter les conflits avec l'API de statut des commits.
Vous pouvez désactiver GitLab CI/CD par projet ou pour tous les nouveaux projets d'une instance.
Lorsque vous désactivez GitLab CI/CD :
/pipelines et /jobs ne sont plus disponibles.Pour désactiver GitLab CI/CD dans votre projet :
Ces modifications ne s'appliquent pas aux projets faisant partie d'une intégration externe.
{{< details >}}
{{< /details >}}
{{< history >}}
ci_delete_old_pipelines. Désactivé par défaut.ci_delete_old_pipelines supprimé dans GitLab 17.9.{{< /history >}}
Définissez une période de rétention pour faciliter la gestion du stockage des pipelines et améliorer les performances du système. Les pipelines plus anciens que la durée configurée sont supprimés automatiquement par un job en arrière-plan. Le nettoyage s'exécute périodiquement en arrière-plan, et non immédiatement lorsqu'un pipeline devient éligible. Les projets présentant un grand arriéré d'anciens pipelines sont nettoyés progressivement au fil de plusieurs exécutions.
Lorsqu'un pipeline est supprimé, ses jobs, job logs et artefacts sont également définitivement supprimés. Tous les pipelines plus anciens que la période de rétention configurée sont éligibles à la suppression, quel que soit leur statut ou s'ils constituent le pipeline le plus récent pour une branche ou un tag donné.
Prérequis :
Pour configurer le nettoyage de pipeline automatique :
2 weeks ou 30 days. La valeur doit être d'au moins un jour et ne pas dépasser le maximum de l'instance (1 an par défaut). Laissez ce champ vide pour ne jamais supprimer automatiquement les pipelines.Pour GitLab Self-Managed, les administrateurs peuvent augmenter la limite supérieure pour le nettoyage de pipeline automatique.