Date de la publication : 18 avril 2025
Lecture : 13 min
Guide des changements cassants et suppressions de GitLab 18.0
Anticipez dès maintenant les suppressions prévues dans notre prochaine version majeure. Évaluez les conséquences pour votre projet, puis consultez les mesures d'atténuation décrites dans la documentation afin de garantir une transition fluide vers GitLab 18.0.
GitLab 18.0, notre prochaine version majeure, inclut de nouvelles fonctionnalités qui repoussent les limites de l'innovation DevSecOps, tandis que certaines options obsolètes sont supprimées. Découvrez dans cet article un récapitulatif complet des évolutions majeures à venir, ainsi que des pistes concrètes pour en limiter l’impact sur vos projets.
Fenêtres de déploiement GitLab 18.0
GitLab.com
Les changements cassants sur GitLab.com sont concentrés sur ces trois périodes clés :
- Du 21 au 23 avril 2025
- Du 28 au 30 avril 2025
- Du 5 au 7 mai 2025
De nombreux autres évolutions continuent d'être déployés au fil des mois. Pour en savoir plus sur les modifications les plus sensibles apportées prévues à ces dates, consultez notre documentation dédie aux changements cassants.
Remarque : exceptionnellement, certaines mises à jour importantes peuvent intervenir légèrement en dehors de ces périodes.
GitLab Self-Managed
GitLab 18.0 est disponible depuis le 15 mai. Consultez le calendrier complet des sorties de nouvelles versions sur cette page.
GitLab Dedicated
La mise à niveau vers GitLab 18.0 aura lieu pendant votre fenêtre de maintenance, entre le 24 et le 29 juin 2025. Pour en savoir plus et connaître votre fenêtre de maintenance, consultez cette page.
Nous mettons également à votre disposition des outils et ressources adaptés pour vous aider à mesurer l'impact de ces changements sur votre environnement et préparer votre passage à la version 18.0. N'hésitez pas à consulter toutes les informations sur ces outils, ressources et les mesures d'atténuation.
En outre, la page des obsolescences répertorie l'ensemble des suppressions prévues dans la version 18.0. Découvrez ci-dessous les nouveautés de cette année et comment vous y préparer selon la configuration de votre déploiement.
Changements cassants
Impact élevé
1. Token pour job CI/CD : suppression du paramètre « Limiter l'accès depuis votre projet »
GitLab.com | GiitLab Self-Managed | GitLab Dedicated
Dans GitLab 14.4, nous avions mis en place le paramètre Limiter l'accès à CI_JOB_TOKEN pour améliorer la sécurité en restreignant l'accès depuis les tokens de job CI/CD de votre projet (CI_JOB_TOKEN) Dans la version 16.3 de GitLab, ce paramètre a été renommé Limiter l'accès à partir de ce projet pour plus de clarté. Dans la version 15.9 de GitLab, nous avions introduit une solution alternative : le paramètre Groupes et projets autorisés. Celui-ci contrôle l'accès au token pour job CI/CD de votre projet à l'aide d'une liste d'autorisations et constitue une amélioration significative par rapport à l'original. La première itération a été rendue obsolète dans GitLab 16.0 et sa suppression est prévue dans GitLab 18.0.
Le paramètre Limiter l'accès à partir de ce projet est désactivé par défaut pour tous les nouveaux projets. Depuis GitLab 16.0, une fois ce paramètre désactivé dans un projet, il n’est plus possible de le réactiver, mais vous pouvez utiliser le paramètre Groupes et projets autorisés pour contrôler l'accès au token pour job de vos projets.
2. Token pour job CI/CD : application de la liste d'autorisation « Groupes et projets autorisés »
GitLab.com | GitLab Self-Managed | GitLab Dedicated
Introduit dans GitLab 15.9, le paramètre « Groupes et projets autorisés » (renommé Limiter l'accès à ce projet dans la version 16.3 de GitLab), vous permet de gérer l'accès au token pour job CI/CD de votre projet. Lorsque le paramètre est défini sur Uniquement ce projet et tous les groupes et projets de la liste d'autorisation, seuls les groupes ou projets explicitement ajoutés à cette liste peuvent accéder à votre projet par le biais d'un token de job.
- Avant GitLab 15.9, le token de job était accessible depuis n'importe quel projet, car la liste d'autorisation était désactivée par défaut et définie sur « Tous les groupes et projets », sans restriction d'accès.
- Depuis GitLab 17.6, les administrateurs des instances GitLab Self-Managed ou GitLab Dedicated peuvent désormais imposer des règles de sécurité plus strictes pour tous les projets et empêcher les chargés de maintenance des projets de sélectionner Tous les groupes et projets. Cette modification garantit un niveau de sécurité plus élevé entre les projets.
- Dans GitLab 18.0, ce paramètre sera activé par défaut. Sur GitLab.com, nous remplirons automatiquement les listes d'autorisations de vos projets en fonction des logs d'authentification de votre projet.
- Pour anticiper ce changement sur GitLab.com, les chargés de maintenance du projet qui utilisent le token de job pour l'authentification inter-projets doivent remplir les listes d'autorisations Groupes et projets autorisés, puis définir le paramètre sur Uniquement ce projet et tous les groupes et projets de la liste d'autorisation. Nous vous encourageons à utiliser les outils de migration disponibles pour automatiser la création de la liste d'autorisation en fonction des logs d'authentification du projet avant le passage à la version GitLab 18.0.
- Les utilisateurs de GitLab Self-Managed doivent remplir les listes d'autorisations avant d'effectuer la mise à niveau vers la version 18.0.
- Les utilisateurs de GitLab Dedicated doivent élaborer, en collaboration avec l'équipe chargée de leur compte GitLab, une approche adaptée à leur instance.
3. Renforcement de la portée des tokens pour le proxy de dépendances
GitLab.com | GitLab Self-Managed | GitLab Dedicated
Actuellement, le proxy de dépendances pour les conteneurs accepte les commandes docker login et docker pull en utilisant des tokens d'accès personnels, de projet ou de groupe, sans vérifier leurs portées.
À partir de GitLab 18.0, il exigera la présence des portées read_registry et write_registry pour valider toute authentification. Après cette modification, les tentatives d'authentification avec des tokens ne disposant pas de ces portées seront rejetées.
Avant de procéder à la mise à niveau, vous devez générer de nouveaux tokens avec les portées requises, puis mettre à jour les variables et scripts de vos workflows avec ces nouveaux jetons.
Vous avez également la possibilité d'utiliser Dependency Token Checker, un script développé par la communauté, qui vous permet de visualiser les tokens et de procéder à leur rotation automatique.
Impact modéré
1. Nouvelles limites de conservation des données relatives aux vulnérabilités sur GitLab.com
GitLab.com - Réservé aux clients Ultimate
À partir de GitLab 18.1, nous mettrons en place progressivement, sur une période de six mois, une nouvelle limite de conservation des données pour les clients de l'édition GitLab Ultimate sur GitLab.com, afin d'améliorer les performances et la fiabilité du système. Celle-ci aura une incidence sur la durée de conservation des données relatives aux vulnérabilité.
Les vulnérabilités datant de plus de 12 mois qui n'ont pas été mises à jour seront automatiquement déplacées vers des archives de stockage à froid qui :
- restent accessibles et téléchargeables via l'interface utilisateur (UI) de GitLab
- sont conservées pendant 3 ans
- sont définitivement supprimées après 3 ans
2. Rejet des stratégies de pull d'image de conteneur qui ne figurent pas dans allowed_pull_policies
GitLab.com | GitLab Self-Managed | GitLab Dedicated
Toutes les stratégies de pull configurées doivent être présentes dans la configuration allowed_pull_policies spécifiée dans le fichier config.toml du runner. Si ce n'est pas le cas, le job devrait échouer avec une erreur de type**incompatible pull policy**.
Actuellement, les jobs ne sont pas rejetés tant qu'au moins une stratégie de pull figure dans allowed-pull-policies, même si d'autres sont exclues.
Dans GitLab 18.0, un job ne sera en échec que si aucune stratégie de pull définie ne figure dans allowed-pull-policies. Toutefois, maintenant, seules les stratégies autorisées dans allowed-pull-policies seront effectivement appliquées. Avec GitLab 18.0, cette distinction risque de provoquer l'échec de jobs qui s'exécutent actuellement avec succès.
3. Fin de la prise en charge de PostgreSQL 14 et 15
GitLab Self-Managed
GitLab suit une cadence de mise à niveau annuelle pour PostgreSQL.
La prise en charge de PostgreSQL 14 et 15 sera supprimée dans GitLab 18.0 et PostgreSQL 16 deviendra la version minimale requise.
PostgreSQL 14 et 15 seront pris en charge pendant l'ensemble du cycle de sortie de nouvelles versions de GitLab 17. PostgreSQL 16 sera également pris en charge pour les instances qui souhaitent effectuer une mise à niveau avant la sortie de GitLab 18.0.
Pour anticiper ce changement, les instances qui n'utilisent pas PostgreSQL Cluster (comme celles installées avec un paquet Omnibus sur une seule instance PostgreSQL), bénéficieront d'une mise à niveau automatique vers PostgreSQL 16 à partir de GitLab 17.11. Si vous utilisez PostgreSQL Cluster ou si vous désactivez cette mise à niveau automatique, vous devrez effectuer une mise à niveau manuelle vers PostgreSQL 16 pour passer à GitLab 18.0. Assurez-vous de disposer de suffisamment d'espace disque pour effectuer la mise à niveau.
4. Obsolescence des templates CI/CD Terraform
GitLab Self-Managed
Les templates CI/CD Terraform sont déclarés obsolètes et sont supprimés dans GitLab 18.0. Les templates concernés sont les suivants :
Terraform.gitlab-ci.ymlTerraform.latest.gitlab-ci.ymlTerraform/Base.gitlab-ci.ymlTerraform/Base.latest.gitlab-ci.yml
GitLab ne pourra pas mettre à jour le binaire terraform dans les images de job vers une version sous licence Business Source License (BSL).
Pour continuer à utiliser Terraform, clonez les templates et l'image Terraform, et maintenez-les à jour si nécessaire. GitLab fournit des instructions détaillées pour migrer vers une image personnalisée.
À la place, nous vous recommandons d'utiliser le nouveau composant CI/CD OpenTofu sur GitLab.com ou le nouveau template CI/CD OpenTofu sur GitLab Self-Managed. Les composants CI/CD ne sont pas encore disponibles sur GitLab Self-Managed. Toutefois, le ticket n° 415638 propose d'ajouter cette fonctionnalité. Si les composants CI/CD deviennent disponibles sur GitLab Self-Managed, le template CI/CD OpenTofu sera supprimé.
En savoir plus sur le nouveau composant CI/CD OpenTofu.
5. Mise à jour majeure du sous-chart Prometheus
GitLab Self-Managed
Avec GitLab 18.0 et le chart GitLab 9.0, le sous-chart Prometheus sera mis à jour de la version 15.3 à la version 27.3.
Avec cette mise à jour, Prometheus 3 sera livré par défaut.
Vous devrez effectuer certaines étapes manuelles pour effectuer la mise à niveau. Si Alertmanager, Node Exporter ou Pushgateway sont activés, vous devrez également mettre à jour vos valeurs Helm.
Veuillez vous référer au guide sur la migration pour plus d'informations.
Impact faible
1. Arrêt de la compilation des paquets SUSE Linux Enterprise Server 15 SP2
GitLab Self-Managed
Le version avec service et support à long terme (LTSS) pour SUSE Linux Enterprise Server (SLES) 15 SP2 a pris fin en décembre 2024.
Par conséquent, nous ne prendrons plus en charge la distribution de SLES SP2 pour les installations de paquets Linux. Veuillez effectuer une mise à niveau vers SLES 15 SP6 pour bénéficier d'une prise en charge continue.
2. Suppression du limiteur de débit Gitaly
GitLab Self-Managed
Auparavant, Gitaly prenait en charge la limitation de débit basée sur RPC. Nous rendons aujourd'hui cette fonctionnalité obsolète, car elle ne donne pas les résultats escomptés. Veuillez consulter le ticket relatif à l'obsolescence pour plus de détails.
Si vous avez procédé à la configuration du limiteur de débit (bientôt obsolète), aucune erreur ne sera renvoyée et celle-ci sera simplement ignorée.
À la place, vous devez utiliser le limiteur de simultanéité.
3. Obsolescence de la prise en charge de l'image du contrôleur NGINX 1.3.1
GitLab Self-Managed
Nous passons à la version 1.11.2 du contrôleur NGINX par défaut, laquelle impose de nouvelles règles de contrôle d'accès basé sur les rôles (RBAC). Les utilisateurs qui utilisent nginx-ingress.rbac.create: false pour gérer leurs propres règles RBAC
devront les mettre à jour avant de migrer vers la version 1.11.2 ou une version ultérieure. Un mécanisme alternatif permet désormais de déployer la version 1.3.1 uniquement si la valeur Helm est définie comme indiqué ci-dessus. Par ailleurs, nous avons ajouté la valeur nginx-ingress.controller.image.disableFallback, qui est définie par défaut sur « false ». Si vous gérez vos propres règles RBAC, vous pouvez définir cette valeur sur « true » une fois les nouvelles règles en place, afin de permettre le déploiement de la version 1.11.2.
La version 17.5 marquera la fin de la prise en charge de l'image 1.3.1 et du mécanisme alternatif, afin de généraliser l'utilisation de la version 1.11.2, plus sécurisée.
4. Mise à jour de la version majeure des analyseurs de tests de sécurité des applications
GitLab.com | GitLab Self-Managed | GitLab Dedicated
Avec GitLab 18.0, les analyseurs utilisés pour les tests de sécurité des applications passeront à de nouvelles versions majeures.
Si vous n'utilisez pas les templates inclus par défaut ou si vous avez épinglé vos versions d'analyseur, pensez à mettre à jour votre job CI/CD en retirant la version épinglée ou en passant à la dernière version majeure.
Jusqu'à GitLab 18.0, les analyseurs seront toujours mis à jour sur les versions 17.0 à 17.11. Ensuite, seuls les analyseurs de la nouvelle version majeure bénéficieront des correctifs et des nouvelles fonctionnalités.
Conformément à notre politique de maintenance, nous ne rétroportons pas les bogues ni les nouvelles fonctionnalités vers les versions obsolètes. Seuls les correctifs de sécurité peuvent être appliqués aux trois dernières versions mineures.
5. API Discovery utilisera les pipelines de branche par défaut
GitLab.com | GitLab Self-Managed | GitLab Dedicated
Dans GitLab 18.0, nous mettrons à jour le comportement par défaut du template CI/CD pour API Discovery (API-Discovery.gitlab-ci.yml).
Jusqu'à GitLab 18.0, il configurait par défaut les jobs pour qu'ils s'exécutent dans des pipelines de merge requests (MR) dès l'ouverture d'une MR.
Dès GitLab 18.0, ce template adoptera le même comportement que les éditions stables de templates des autres scanners d'arbre de syntaxe abstraite (AST) :
- Par défaut, le template exécutera des jobs de scan dans les pipelines de branche.
- Vous pourrez définir la variable CI/CD AST_ENABLE_MR_PIPELINES: true pour utiliser les pipelines MR lors de l'ouverture d'une MR. Le suivi de la mise en œuvre de cette variable est disponible via le ticket n° 410880.
6. Réduction par défaut de la valeur du DAST DAST_DEVTOOLS_API_TIMEOUT
GitLab.com | GitLab Self-Managed | GitLab Dedicated
La variable d'environnement DAST_DEVTOOLS_API_TIMEOUT détermine la durée pendant laquelle un test dynamique de sécurité des applications (DAST) attend une réponse du navigateur. Avant GitLab 18.0, la variable avait une valeur statique de 45 secondes. Dès GitLab 18.0, la variable d'environnement DAST_DEVTOOLS_API_TIMEOUT aura une valeur dynamique, calculée en fonction d'autres configurations de délai d'attente dépassé.
Dans la plupart des cas, la valeur de 45 secondes était supérieure à la valeur du délai d'attente dépassé de nombreuses fonctions du scanner. Le passage à un calcul dynamique permet d'adapter la variable DAST_DEVTOOLS_API_TIMEOUT à un plus grand nombre de situations.
Outils et ressources pour gérer l'impact sur votre environnement
Nous avons développé des outils spécifiques pour aider nos clients à comprendre l'impact de ces changements planifiés sur leur(s) instance(s) GitLab. Après avoir évalué l'impact sur votre projet, consultez les mesures d'atténuation décrites dans la documentation pour assurer une transition fluide vers GitLab 18.0.
- Obsolescence de la recherche avancée : cet outil s'appuie sur l'API de recherche avancée de GitLab pour repérer les chaînes liées aux obsolescences dans vos groupes et projets, et signale aussi les fichiers nécessitant une vérification manuelle. Remarque : peut comporter des faux positifs.
- Assistant de détection de prise en charge de la compilation pour l'analyse des dépendances : cet outil détecte les projets concernés par trois obsolescences liées à l'analyse des dépendances (1, 2, 3 ; toutes reportées à la version 19.0) et s'appuie sur l'API pour analyser les fichiers et les nom de jobs CI.
- GitLab Detective (GitLab Auto-géré uniquement) : cet outil expérimental analyse automatiquement votre installation GitLab pour détecter les problèmes connus, en s'appuyant sur des vérifications poussées des fichiers de configuration et valeurs issues de la base de données. Remarque : l’outil doit s'exécuter directement sur vos nœuds GitLab.
Pour vous accompagner dans cette transition, nous avons lancé sur GitLab University des micro-cours pratiques (de 15 minutes maximum) dédiés à la préparation et à la mise en œuvre des actions d'atténuation nécessaires. Commencez votre parcours d'apprentissage ici.
Si vous disposez d'un forfait payant et que vous avez des questions ou besoin d'aide concernant ces changements, veuillez créer un ticket d'assistance sur le portail d'assistance GitLab.
Si vous utilisez la version gratuite de Gitlab.com, vous pouvez obtenir de l'aide via les ressources communautaires : documentation GitLab, forum de la communauté GitLab et Stack Overflow.