GitLab 17.0 comportait 80 changements cassants. GitLab 18.0 en comptait 27. La prochaine release GitLab 19.0 devrait en inclure 15.
Nous savons que la gestion des changements cassants lors d'une mise à niveau est une opération chronophage : elle exige une analyse approfondie et une coordination entre les différentes équipes de votre organisation. C'est pourquoi nous avons introduit une procédure d'approbation des changements cassants qui impose une atténuation de l'impact et une validation de la direction avant toute mise en œuvre. Ce processus porte ses fruits, et nous nous engageons à continuer de réduire ce nombre.
Vous trouverez ci-dessous l'ensemble des changements cassants de GitLab 19.0, classés par type de déploiement et niveau d'impact, accompagnés des mesures d'atténuation nécessaires pour effectuer votre mise à niveau en toute confiance.
Fenêtres de déploiement
Voici les fenêtres de déploiement à connaître.
GitLab.com
Les changements cassants pour GitLab.com seront limités à ces deux fenêtres :
- 4-6 mai 2026 (09 h 00-22 h 00 UTC) – fenêtre principale
- 11-13 mai 2026 (09 h 00-22 h 00 UTC) – fenêtre de secours
De nombreux autres changements continueront d'être déployés tout au long du mois. Pour en savoir plus sur les changements prévus dans chacune de ces fenêtres, consultez notre documentation.
Remarque : dans des circonstances exceptionnelles, certains changements cassants peuvent être déployés légèrement en dehors de ces fenêtres.
GitLab Self-Managed
GitLab 19.0 sera disponible à partir du 21 mai 2026.
Pour en savoir plus, consultez le calendrier des releases.
GitLab Dedicated
La mise à niveau vers GitLab 19.0 aura lieu pendant la fenêtre de maintenance qui vous a été attribuée. Vous pouvez en savoir plus et consulter votre fenêtre de maintenance attribuée dans votre portail Switchboard. Les instances GitLab Dedicated sont maintenues en release N-1 : la mise à niveau vers GitLab 19.0 aura donc lieu pendant la fenêtre de maintenance de la semaine du 22 juin 2026.
Consultez la page des dépréciations pour voir la liste complète des éléments dont la suppression est prévue dans GitLab 19.0. Poursuivez votre lecture pour découvrir les changements à venir et savoir comment vous préparer en fonction de votre type de déploiement.
Changements cassants
Voici les changements à impact élevé.
Impact élevé
1. Prise en charge de NGINX Ingress remplacée par la passerelle API avec Envoy Gateway
GitLab Self-Managed (chart Helm)
Le chart Helm de GitLab intégrait NGINX Ingress comme composant réseau par défaut. NGINX Ingress a atteint sa fin de vie en mars 2026, et GitLab effectue désormais la transition vers la passerelle API avec Envoy Gateway comme nouvelle configuration par défaut.
À partir de GitLab 19.0, la passerelle API et avec Envoy Gateway intégré deviennent la configuration réseau par défaut. Si la migration vers Envoy Gateway n'est pas immédiatement possible pour votre déploiement, vous pouvez réactiver explicitement NGINX Ingress, qui reste disponible jusqu'à sa suppression prévue dans GitLab 20.0.
Ce changement n'affecte pas :
- NGINX utilisé dans le paquet Linux
- Les instances chart Helm GitLab et GitLab Operator qui utilisent un contrôleur Ingress ou une passerelle API géré en externe
GitLab assurera une maintenance de sécurité au mieux de ses capacités pour le chart et les builds NGINX Ingress dupliqués jusqu'à leur suppression définitive. Pour garantir une transition fluide, planifiez votre migration vers la passerelle API fournie ou vers un contrôleur Ingress géré de manière externe avant la mise à niveau vers GitLab 19.0.
2. Suppression de PostgreSQL, Redis et MinIO intégrés du chart Helm GitLab
GitLab Self-Managed (chart Helm)
Le chart Helm GitLab intégrait depuis longtemps Bitnami PostgreSQL, Bitnami Redis et une duplication du chart MinIO officiel afin de simplifier la mise en place de GitLab dans les environnements de test et les études de faisabilité. En raison de modifications de licences, de la maintenance des projets et de la disponibilité des images publiques, ces composants seront supprimés du chart Helm GitLab et de GitLab Operator sans remplacement.
Ces charts sont explicitement documentés comme non recommandés pour un usage en production. Leur seul objectif était de permettre la mise en place rapide d'environnements de test.
Si vous exécutez une instance avec PostgreSQL, Redis ou MinIO intégrés, suivez le guide de migration pour configurer des services externes avant la mise à niveau vers GitLab 19.0. Redis et PostgreSQL, fournis par le paquet Linux, ne sont pas concernés par ce changement.
3. Suppression de l'autorisation OAuth Resource Owner Password Credentials (ROPC)
GitLab.com | GitLab Self-Managed | GitLab Dedicated
La prise en charge de l'autorisation Resource Owner Password Credentials (ROPC) en tant que flux OAuth sera entièrement supprimée dans GitLab 19.0. Cette décision est conforme à la norme OAuth RFC Version 2.1, qui supprime le ROPC en raison de ses limitations de sécurité inhérentes.
GitLab exigeait déjà l'authentification du client pour le ROPC sur GitLab.com depuis le 8 avril 2025. Un paramètre administrateur a été ajouté dans GitLab 18.0 pour permettre une désactivation contrôlée avant la suppression.
Après la mise à niveau vers GitLab 19.0, le ROPC ne pourra plus être utilisé en aucune circonstance, même avec des identifiants client. Toute application ou intégration utilisant ce type d'autorisation doit migrer vers un flux OAuth pris en charge, tel que le flux Authorization Code, avant la mise à niveau.
4. Fin de la prise en charge de PostgreSQL 16 – PostgreSQL 17 devient la version minimale requise
GitLab Self-Managed
GitLab suit une cadence annuelle de mise à niveau pour PostgreSQL. Dans GitLab 19.0, PostgreSQL 17 devient la version minimale requise, et la prise en charge de PostgreSQL 16 est supprimée.
PostgreSQL 17 est disponible depuis GitLab 18.9, vous pouvez donc effectuer la mise à niveau à tout moment avant la sortie de GitLab 19.0.
Pour les instances exécutant une seule instance PostgreSQL installée via le paquet Linux, une mise à niveau automatique vers PostgreSQL 17 pourra être tentée lors de la mise à niveau vers GitLab 18.11. Assurez-vous de disposer d'un espace disque suffisant pour cette opération.
Pour les instances utilisant PostgreSQL Cluster, ou celles ayant refusé la mise à niveau automatique, une mise à niveau manuelle vers PostgreSQL 17 est nécessaire avant de passer à GitLab 19.0.
Avis d'obsolescence | Guide de mise à niveau
Impact moyen
Voici les changements cassants à impact moyen.
1. Fin de la prise en charge d'Ubuntu 20.04 par le paquet Linux
GitLab Self-Managed
La prise en charge standard d'Ubuntu 20.04 a pris fin en mai 2025. Conformément à la politique de plateformes prises en charge par le paquet Linux de GitLab, les paquets sont retirés lorsque l'éditeur cesse de prendre en charge le système d'exploitation.
À partir de GitLab 19.0, les paquets ne seront plus fournis pour Ubuntu 20.04. GitLab 18.11 sera la dernière release avec des paquets Linux pour cette distribution.
Si vous exécutez actuellement GitLab sur Ubuntu 20.04, vous devez effectuer la mise à niveau vers Ubuntu 22.04 ou un autre système d'exploitation pris en charge avant de passer à GitLab 19.0. Canonical fournit un guide de mise à niveau pour faciliter la migration.
2. Suppression de la prise en charge de Redis 6
GitLab Self-Managed
Dans GitLab 19.0, la prise en charge de Redis 6 est supprimée. Avant la mise à niveau, les instances utilisant un déploiement Redis 6 externe doivent migrer vers Redis 7.2 ou Valkey 7.2, disponible en version bêta depuis GitLab 18.9 avec une disponibilité générale prévue pour GitLab 19.0.
Le Redis intégré au paquet Linux utilise Redis 7 depuis GitLab 16.2 et n'est pas concerné. Seules les instances utilisant un déploiement Redis 6 externe doivent agir.
Des ressources de migration sont disponibles pour les principales plateformes :
- AWS ElastiCache : mise à niveau vers Redis 7.2 ou Valkey 7.2
- GCP Memorystore : mise à niveau vers Redis 7.2 ou Valkey 7.2
- Azure Cache pour Redis : Redis 7.2 ou Valkey 7.2 Managed n'est pas encore disponible sur Azure. Vous pouvez opter pour l'auto-hébergement sur des machines virtuelles Azure ou AKS, ou utiliser l'installation par paquet Linux, qui prendra en charge Valkey 7.2 avec la disponibilité générale de GitLab 19.0.
- Auto-hébergé : effectuez la mise à niveau de votre instance Redis 6 vers Redis 7.2 ou Valkey 7.2.
Avis d'obsolescence | Documentation des prérequis
3. Remplacement de l'image heroku/builder:22 par heroku/builder:24
GitLab.com | GitLab Self-Managed | GitLab Dedicated
L'image builder cloud-native buildpack (CNB) utilisée dans la fonctionnalité Auto DevOps a été mise à jour vers heroku/builder:24. Ce changement concerne les pipelines qui utilisent l'auto-build-image fournie par l'étape Auto Build de la fonctionnalité Auto DevOps.
Bien que la plupart des charges de travail ne soient pas concernées, cette évolution peut constituer un changement cassant pour certains utilisateurs. Avant la mise à niveau, consultez les notes de release de la pile Heroku-24 et les notes de mise à niveau pour évaluer l'impact sur votre environnement.
Si vous devez continuer à utiliser heroku/builder:22 après GitLab 19.0, définissez la variable CI/CD AUTO_DEVOPS_BUILD_IMAGE_CNB_BUILDER sur heroku/builder:22.
4. Suppression de Mattermost du paquet Linux
GitLab Self-Managed
Dans GitLab 19.0, Mattermost est supprimé du paquet Linux. Mattermost a été intégré à GitLab pour la première fois en 2015, mais a depuis développé ses propres options de déploiement autonome. De plus, avec Mattermost v11, le SSO GitLab a été rendu obsolète dans l'offre gratuite, ce qui réduit la valeur de l'intégration fournie.
Les clients qui n'utilisent pas le paquet Mattermost ne seront pas concernés. Si vous l'utilisez actuellement, consultez la documentation Mattermost relative à la migration de GitLab Omnibus vers Mattermost Standalone pour obtenir les instructions de migration.
5. Fin de la prise en charge des distributions SUSE par le paquet Linux
GitLab Self-Managed
Dans GitLab 19.0, la prise en charge des distributions SUSE par le paquet Linux prend fin. Cela concerne :
- openSUSE Leap 15.6
- SUSE Linux Enterprise Server 12.5
- SUSE Linux Enterprise Server 15.6
GitLab 18.11 sera la dernière release avec des paquets Linux pour ces distributions. La solution recommandée consiste à migrer vers un déploiement Docker de GitLab sur votre distribution existante, ce qui évite de devoir changer de système d'exploitation pour continuer à profiter des mises à niveau.
Impact faible
Voici les changements cassants à impact faible.
1. Suppression de Spamcheck du paquet Linux et du chart Helm GitLab
GitLab Self-Managed
Dans GitLab 19.0, Spamcheck est supprimé du paquet Linux et du chart Helm GitLab. Son utilisation concerne principalement les grandes instances publiques, ce qui constitue un cas marginal dans la base de clients GitLab. Cette suppression réduit la taille du paquet et l'empreinte des dépendances pour la majorité des clients.
Les clients qui n'utilisent pas actuellement Spamcheck ne seront pas concernés. Si vous utilisez le paquet Spamcheck, vous pouvez le déployer séparément à l'aide de Docker. Aucune migration de données n'est nécessaire.
2. Suppression de l'intégration pour les commandes slash Slack
GitLab Self-Managed | GitLab Dedicated
L'intégration pour les commandes slash Slack a été rendue obsolète au profit de l'application GitLab pour Slack, qui offre une intégration plus sécurisée avec les mêmes fonctionnalités.
À partir de GitLab 19.0, les utilisateurs ne pourront plus configurer ni utiliser les commandes slash Slack. Cette intégration n'existe que sur GitLab Self-Managed et GitLab Dedicated – les utilisateurs de GitLab.com ne sont pas concernés.
Pour vérifier si votre instance est concernée, consultez les instructions de vérification d'impact.
3. Fin de la prise en charge des mots de passe d'application de l'importation Bitbucket Cloud via l'API
GitLab.com | GitLab Self-Managed | GitLab Dedicated
Atlassian a rendu obsolètes les mots de passe d'application (authentification par nom d'utilisateur et mot de passe) pour Bitbucket Cloud et a annoncé que cette méthode d'authentification cessera de fonctionner le 9 juin 2026.
À partir de GitLab 19.0, l'importation de dépôts depuis Bitbucket Cloud via l'API GitLab nécessite des tokens d'API utilisateur au lieu des mots de passe d'application. Les utilisateurs qui importent depuis Bitbucket Server, ou depuis Bitbucket Cloud via l'interface GitLab, ne sont pas concernés.
Avis d'obsolescence | Vérification d'impact
4. Suppression de l'onglet Tendance de la page Explorer les projets
GitLab.com | GitLab Self-Managed | GitLab Dedicated
L'onglet Tendance dans Explorer > Projets et les arguments GraphQL associés sont supprimés dans GitLab 19.0. L'algorithme de tendances ne prend en compte que les projets publics, ce qui le rend inefficace pour les instances GitLab Self-Managed qui utilisent principalement une visibilité de projet interne ou privée.
Au cours du mois précédant la sortie de GitLab 19.0, l'onglet Tendance sur GitLab.com redirigera vers l'onglet Actif, qui sera trié par étoiles par ordre décroissant.
Sont également supprimés : l'argument trending dans les types GraphQL Query.adminProjects, Query.projects et Organization.projects.
5. Mises à jour des pilotes de stockage du registre de conteneurs
GitLab Self-Managed
Deux pilotes de stockage legacy du registre de conteneurs sont remplacés dans GitLab 19.0 :
- Pilote de stockage Azure : le pilote legacy
azuredevient un alias pour le nouveau piloteazure_v2. Aucune action manuelle n'est requise, mais une migration proactive est recommandée pour une fiabilité et des performances améliorées. Consultez la documentation du stockage objet pour les étapes de migration. Avis d'obsolescence - Pilote de stockage S3 (AWS SDK v1) : le pilote legacy
s3devient un alias pour le nouveau pilotes3_v2. Le pilotes3_v2ne prend pas en charge Signature Version 2 : toute configurationv4auth: falsesera ignorée de manière transparente. Migrez vers Signature Version 4 avant la mise à niveau. Avis d'obsolescence
6. Suppression de la mutation GraphQL ciJobTokenScopeAddProject
GitLab.com | GitLab Self-Managed | GitLab Dedicated
La mutation GraphQL ciJobTokenScopeAddProject a été rendue obsolète au profit de ciJobTokenScopeAddGroupOrProject, introduite avec les changements de portée des jetons de jobs CI/CD dans GitLab 18.0. Mettez à jour toute automatisation ou tout outil utilisant la mutation obsolète avant la mise à niveau.
7. Suppression de l'attribut ci_job_token_scope_enabled de l'API Projects
GitLab.com | GitLab Self-Managed | GitLab Dedicated
L'attribut ci_job_token_scope_enabled de l'API REST Projects est supprimé dans GitLab 19.0. Cet attribut a été rendu obsolète dans GitLab 18.0 lorsque le paramètre sous-jacent a été supprimé, et renvoie depuis toujours la valeur false.
Pour contrôler l'accès des jetons de jobs CI/CD, utilisez les paramètres de projet des jetons de jobs CI/CD.
8. Application de la limite de pagination pour les requêtes non authentifiées sur l'API Projects de GitLab.com
GitLab.com
Afin de maintenir la stabilité de la plateforme et de garantir des performances homogènes, une limite d'offset maximale de 50 000 sera appliquée à toutes les requêtes non authentifiées sur l'API REST Projects List de GitLab.com. Par exemple, le paramètre page sera limité à 2 500 pages lors de la récupération de 20 résultats par page.
Les workflows nécessitant l'accès à davantage de données doivent utiliser des paramètres de pagination par clé. Cette limite s'applique uniquement à GitLab.com. Sur GitLab Self-Managed et GitLab Dedicated, la limite d'offset sera désactivée par défaut avec un feature flag.
Ressources pour gérer l'impact
Nous avons développé des outils spécifiques pour aider les clients à comprendre l'impact de ces changements prévus sur leur(s) instance(s) GitLab. Une fois que vous avez évalué votre impact, nous vous recommandons de consulter les mesures d'atténuation fournies dans la documentation relative à chaque changement afin de garantir une transition fluide vers GitLab 19.0.
GitLab Detective (GitLab Self-Managed uniquement) : cet outil expérimental vérifie automatiquement une installation GitLab à la recherche de problèmes connus en examinant les fichiers de configuration et les valeurs de la base de données. Remarque : il doit être exécuté directement sur vos nœuds GitLab.
Si vous disposez d'un abonnement payant et avez des questions ou besoin d'assistance concernant ces changements, veuillez ouvrir un ticket sur le portail d'assistance GitLab.
Si vous utilisez la version gratuite de GitLab.com, vous pouvez accéder à une assistance supplémentaire via les ressources communautaires telles que la documentation GitLab, le forum GitLab et Stack Overflow.
