doc-locale/fr-fr/administration/settings/continuous_integration.md
{{< details >}}
{{< /details >}}
Configurez les paramètres CI/CD de votre instance GitLab dans la zone Admin.
Prérequis :
Les paramètres suivants sont disponibles :
Personnalisez les paramètres CI/CD, notamment Auto DevOps, les runners d'instance et les artefacts de job.
Pour accéder à ces paramètres :
Configurez Auto DevOps pour s'exécuter pour tous les projets qui n'ont pas de fichier .gitlab-ci.yml. Cela s'applique à la fois aux projets existants et aux nouveaux projets.
Pour configurer Auto DevOps pour tous les projets de votre instance :
Rendez les runners d'instance disponibles pour tous les nouveaux projets par défaut.
Pour rendre les runners d'instance disponibles aux nouveaux projets :
Ajoutez un texte explicatif sur les runners d'instance. Ce texte apparaît dans les paramètres de runner de tous les projets.
Pour ajouter des détails sur les runners d'instance :
Pour afficher les détails rendus :
Partagez un runner de projet avec plusieurs projets.
Prérequis :
Pour partager un runner de projet avec plusieurs projets :
Contrôlez la façon dont les artefacts de job sont stockés et gérés dans votre instance GitLab.
Définissez des limites de taille pour les artefacts de job afin de contrôler l'utilisation du stockage. Chaque fichier d'artefact dans un job a une taille maximale par défaut de 100 Mo.
Les artefacts de job définis avec artifacts:reports peuvent avoir des limites différentes. Lorsque des limites différentes s'appliquent, la valeur la plus petite est utilisée.
[!note] Ce paramètre s'applique à la taille du fichier d'archive final, et non aux fichiers individuels d'un job.
Vous pouvez configurer les limites de taille des artefacts pour :
Pour les limites de GitLab.com, voir Taille maximale des artefacts.
Pour modifier la taille maximale des artefacts pour une instance :
Pour modifier la taille maximale des artefacts pour un groupe ou un projet :
Définissez la durée de conservation des artefacts de job avant leur suppression automatique. La durée d'expiration par défaut est de 30 jours.
La syntaxe de la durée est décrite dans artifacts:expire_in. Les définitions de job individuelles peuvent remplacer cette valeur par défaut dans le fichier .gitlab-ci.yml du projet.
Les modifications apportées à ce paramètre s'appliquent uniquement aux nouveaux artefacts. Les artefacts existants conservent leur durée d'expiration initiale. Pour obtenir des informations sur l'expiration manuelle des anciens artefacts, consultez la documentation de dépannage.
Pour définir la durée d'expiration par défaut des artefacts de job :
Conservez les artefacts du pipeline réussi le plus récent pour chaque référence Git (branche ou tag), quelle que soit leur durée d'expiration.
Par défaut, ce paramètre est activé.
Ce paramètre a priorité sur les paramètres du projet. S'il est désactivé pour une instance, il ne peut pas être activé pour des projets individuels.
Lorsque cette fonctionnalité est désactivée, les artefacts conservés existants n'expirent pas immédiatement. Un nouveau pipeline réussi doit s'exécuter sur une branche avant que ses artefacts puissent expirer.
[!note] Tous les paramètres d'application ont un intervalle d'expiration du cache personnalisable, ce qui peut retarder l'effet des modifications de paramètres.
Pour conserver les artefacts des derniers pipelines réussis :
Pour permettre aux artefacts d'expirer selon leurs paramètres d'expiration, décochez plutôt la case.
Contrôlez si une page d'avertissement doit s'afficher lorsque les utilisateurs consultent des artefacts de job via GitLab Pages. Cet avertissement signale les risques de sécurité potentiels liés au contenu généré par les utilisateurs.
La page d'avertissement de redirection externe est affichée par défaut. Pour la masquer :
Archivez automatiquement les anciens pipelines et tous leurs jobs après une période spécifiée. Les jobs archivés :
La durée d'archivage est mesurée à partir du moment de la création du pipeline. Elle doit être d'au moins 1 jour. Voici des exemples de durées valides : 15 days, 1 month et 2 years. Laissez ce champ vide pour ne jamais archiver les pipelines automatiquement.
Pour GitLab.com, voir l'archivage des pipelines.
Pour configurer l'archivage des jobs :
{{< history >}}
{{< /history >}}
Contrôlez si les variables CI/CD de pipeline sont autorisées par défaut dans les nouveaux projets des nouveaux groupes.
Lorsqu'il est désactivé, le paramètre rôle par défaut pour utiliser les variables de pipeline est défini sur Aucun rôle autorisé pour les nouveaux groupes, ce qui se répercute sur les nouveaux projets dans les nouveaux groupes. Lorsqu'il est activé, le paramètre est défini par défaut sur Développeur.
[!warning] Pour conserver les paramètres par défaut les plus sécurisés pour les nouveaux groupes et projets, il est recommandé de définir ce paramètre sur désactivé.
Pour autoriser les variables CI/CD de pipeline par défaut dans tous les nouveaux projets des nouveaux groupes :
Après la création d'un groupe ou d'un projet, les mainteneurs peuvent choisir un paramètre différent.
Définissez toutes les nouvelles variables CI/CD dans les projets et les groupes comme protégées par défaut. Les variables protégées ne sont disponibles que pour les pipelines qui s'exécutent sur des branches protégées ou des tags protégés.
Pour protéger toutes les nouvelles variables CI/CD par défaut :
{{< history >}}
{{< /history >}}
Limitez le nombre de fichiers YAML externes qu'un pipeline peut inclure à l'aide du mot-clé include. Cette limite prévient les problèmes de performance lorsque les pipelines incluent trop de fichiers.
Par défaut, un pipeline peut inclure jusqu'à 150 fichiers. Lorsqu'un pipeline dépasse cette limite, il échoue avec une erreur.
Pour définir le nombre maximum de fichiers inclus par pipeline :
{{< history >}}
{{< /history >}}
Limitez le nombre de pipelines downstream pouvant être déclenchés par minute à partir d'une source unique.
Le taux maximum de déclenchement des pipelines downstream limite le nombre de pipelines downstream pouvant être déclenchés par minute pour une combinaison donnée de projet, d'utilisateur et de commit. La valeur par défaut est 0, ce qui signifie qu'il n'y a aucune restriction.
Définissez un chemin et un nom de fichier personnalisés à utiliser par défaut pour les fichiers de configuration CI/CD dans tous les nouveaux projets. Par défaut, GitLab utilise le fichier .gitlab-ci.yml dans le répertoire racine du projet.
Ce paramètre s'applique uniquement aux nouveaux projets créés après sa modification. Les projets existants continuent d'utiliser leur chemin de fichier de configuration CI/CD actuel.
Pour définir un chemin de fichier de configuration CI/CD par défaut personnalisé :
Les projets individuels peuvent remplacer cette valeur par défaut d'instance en spécifiant un fichier de configuration CI/CD personnalisé.
Contrôlez si une bannière d'orientation doit être affichée dans les merge requests qui n'ont pas de pipelines. Cette bannière fournit une procédure pas à pas sur la façon d'ajouter un fichier .gitlab-ci.yml.
La bannière de suggestion de pipeline est affichée par défaut. Pour la masquer :
{{< history >}}
{{< /history >}}
Contrôlez si une bannière encourageant la migration de Jenkins vers GitLab CI/CD doit être affichée. Cette bannière apparaît dans les merge requests pour les projets ayant l'intégration Jenkins activée.
La bannière de migration Jenkins est affichée par défaut. Pour la masquer :
Configurez la validation des paquets NuGet, les limites des paquets Helm, les limites de taille des fichiers de paquets et le transfert de paquets.
Pour accéder à ces paramètres :
Ignorez la validation des métadonnées projectUrl, iconUrl et licenseUrl dans les paquets NuGet.
Par défaut, GitLab valide ces URL. Si votre instance GitLab n'a pas d'accès à Internet, cette validation échoue et vous empêche de téléverser des paquets NuGet.
Pour ignorer la validation de l'URL des métadonnées des paquets NuGet :
Définissez le nombre maximum de paquets Helm pouvant être répertoriés par canal.
Pour définir la limite des paquets Helm :
Définissez les limites de taille de fichier maximales pour chaque type de paquet afin de contrôler l'utilisation du stockage et de maintenir les performances du système.
Vous pouvez configurer les limites de taille de fichier maximales pour les paquets suivants, en octets :
Pour configurer les limites de taille des fichiers de paquets :
{{< details >}}
{{< /details >}}
Contrôlez si les demandes de paquets sont transférées vers les registres publics lorsque les paquets ne sont pas trouvés dans votre gistre de paquets GitLab.
Par défaut, GitLab transfère les demandes de paquets vers leurs registres publics respectifs :
Pour désactiver le transfert de paquets :
Pour désactiver le transfert des demandes pour les paquets Maven, voir Paquets Maven dans le registre de paquets.
Configurez la gestion des versions des runners et les paramètres d'enregistrement.
Pour accéder à ces paramètres :
Contrôlez si votre instance récupère les données officielles de version des runners depuis GitLab.com pour déterminer si des runners nécessitent des mises à niveau.
Par défaut, GitLab récupère les données de version des runners. Pour arrêter de récupérer ces données :
{{< history >}}
{{< /history >}}
Contrôlez qui peut enregistrer des runners et si les jetons d'enregistrement sont autorisés.
[!warning] L'option de transmission de jetons d'enregistrement de runner et la prise en charge de certains arguments de configuration sont considérées comme héritées et ne sont pas recommandées. Utilisez le workflow de création de runner pour générer un jeton d'authentification permettant d'enregistrer des runners. Ce processus assure une traçabilité complète de la propriété des runners et renforce la sécurité de votre flotte de runners.
Pour plus d'informations, voir Migration vers le nouveau workflow d'enregistrement des runners.
Par défaut, les jetons d'enregistrement des runners ainsi que l'enregistrement des membres de projet et de groupe sont autorisés. Pour restreindre l'enregistrement des runners :
[!note] Lorsque vous désactivez l'enregistrement des runners pour les membres du projet, le jeton d'enregistrement est automatiquement renouvelé. Le jeton précédent devient invalide et vous devez utiliser le nouveau jeton d'enregistrement pour le projet.
Contrôlez si les membres d'un groupe spécifique peuvent enregistrer des runners.
Prérequis :
Pour restreindre l'enregistrement des runners pour un groupe spécifique :
Contrôlez comment les jetons de job CI/CD peuvent accéder à vos projets.
Pour accéder à ces paramètres :
{{< history >}}
{{< /history >}}
Exigez que tous les projets contrôlent l'accès aux jetons de job à l'aide d'une liste d'autorisation.
Lorsque ce paramètre est activé :
Pour plus d'informations, voir contrôler l'accès des jetons de job à votre projet.
Pour appliquer les listes d'autorisation des jetons de job :
Contrôlez comment les job logs CI/CD sont stockés et traités.
Pour accéder à ces paramètres :
{{< history >}}
ci_enable_live_trace feature flag.ci_enable_live_trace supprimé dans GitLab 18.0.{{< /history >}}
Utilisez Redis pour la mise en cache temporaire des job logs et téléversez progressivement les logs archivés vers le stockage objet. Cela améliore les performances et réduit l'utilisation de l'espace disque.
Pour plus d'informations, voir journalisation incrémentale.
Prérequis :
Pour activer la journalisation incrémentale pour tous les projets :
{{< details >}}
{{< /details >}}
{{< history >}}
{{< /history >}}
Contrôlez quels projets peuvent publier des composants dans le catalogue CI/CD.
Pour accéder à ces paramètres :
Par défaut, tout projet peut publier des composants dans le catalogue CI/CD. Vous pouvez restreindre la publication à des projets spécifiques en configurant une liste d'autorisation.
Lorsque la liste d'autorisation est :
Vous pouvez définir des entrées dans la liste d'autorisation avec :
my-group/my-project.my-group/.* : tous les projets du groupe.my-group/security-.* : Projets commençant par security-.Pour configurer la liste d'autorisation de publication dans le catalogue CI/CD :
Les projets ne figurant pas dans la liste d'autorisation reçoivent une erreur not authorized to publish lorsqu'ils tentent de publier une version de composant.
{{< details >}}
{{< /details >}}
{{< history >}}
required_pipelines. Désactivé par défaut.{{< /history >}}
[!warning] Cette fonctionnalité a été rendue obsolète dans GitLab 15.9 et a été supprimée dans la version 17.0. À partir de la version 17.4, elle est disponible uniquement derrière le feature flag
required_pipelines, désactivé par défaut. Utilisez plutôt les pipelines de conformité. Ce changement est un changement cassant.
Vous pouvez définir un modèle CI/CD comme configuration de pipeline requise pour tous les projets d'une instance GitLab. Vous pouvez utiliser un modèle provenant de :
Les modèles CI/CD par défaut.
Un modèle personnalisé stocké dans un dépôt de modèles d'instance.
[!note] Lorsque vous utilisez une configuration définie dans un dépôt de modèles d'instance, les mots-clés
include:imbriqués (y comprisinclude:file,include:local,include:remoteetinclude:template) ne fonctionnent pas.
La configuration CI/CD du projet est fusionnée dans la configuration de pipeline requise lors de l'exécution d'un pipeline. La configuration fusionnée est identique à ce qu'elle serait si la configuration de pipeline requise ajoutait la configuration du projet avec le mot-clé include. Pour afficher la configuration fusionnée complète d'un projet, utilisez Afficher la configuration complète dans l'éditeur de pipeline.
Pour sélectionner un modèle CI/CD pour la configuration de pipeline requise :