Mehdi Assabbane
← Tous les articles

GitLab 19 : les changements majeurs à vérifier avant de mettre à jour

Mehdi Assabbane ·

En bref

  • GitLab 19.0 est disponible en auto-hébergé depuis le 21 mai 2026. Comme chaque version majeure, elle supprime des fonctionnalités dépréciées : GitLab en annonçait 17 dans son guide.
  • Les plus impactantes : PostgreSQL 17 devient obligatoire, suppression du flux OAuth ROPC, et, pour le chart Helm, remplacement de NGINX Ingress par Envoy Gateway et retrait de PostgreSQL, Redis et MinIO intégrés.
  • Ubuntu 20.04 et SUSE ne sont plus supportés pour les paquets Linux : GitLab 18.11 est la dernière version disponible sur ces systèmes.

Introduction

Chaque version majeure de GitLab est l'occasion de supprimer des fonctionnalités annoncées comme dépréciées. GitLab 17.0 en comptait 80, 18.0 en comptait 27 ; pour 19.0, le guide publié en avril 2026 en annonçait 17. Moins nombreuses, elles touchent pourtant des éléments centraux : la base de données, l'authentification des intégrations et, pour les déploiements Kubernetes, le point d'entrée réseau.

Si vous êtes encore en 18.x, ou si vos mises à jour sont bloquées, cet article recense ce qu'il faut vérifier avant de passer à la branche 19, qui est aussi celle qui reçoit désormais les correctifs de sécurité.

Les changements à fort impact

PostgreSQL 17 obligatoire

GitLab 19.0 abandonne PostgreSQL 16 : PostgreSQL 17 est la version minimale. PostgreSQL 17 est disponible depuis GitLab 18.9.

  • Sur une installation par paquet Linux mono-instance, la base intégrée peut être mise à jour automatiquement lors du passage en 18.11 : vérifiez l'espace disque au préalable, la mise à jour nécessite de copier les données.
  • Avec un cluster PostgreSQL, une base externe ou si vous avez désactivé la mise à jour automatique, la mise à jour est manuelle.
sudo gitlab-psql -c 'SELECT version();'

Affiche la version de la base PostgreSQL intégrée à GitLab (installation par paquet).

sudo du -sh /var/opt/gitlab/postgresql/data
df -h /var/opt/gitlab

Mesure la taille de la base et l'espace disponible, pour s'assurer que la mise à jour peut se faire.

Suppression du flux OAuth ROPC

Le flux OAuth Resource Owner Password Credentials (ROPC), où une application envoie directement l'identifiant et le mot de passe de l'utilisateur, est supprimé sur toutes les offres (GitLab.com, auto-hébergé, Dedicated). Il ne fonctionnera plus après 19.0, même avec des identifiants client.

Recensez les scripts et intégrations qui obtiennent un jeton avec grant_type=password et migrez-les vers un flux supporté, comme Authorization Code, ou vers des jetons d'accès personnels, de groupe ou de projet selon le cas.

grep -rn "grant_type=password\|grant_type.*password" ~/scripts /opt/integrations 2>/dev/null

Recherche les appels ROPC dans vos scripts (adaptez les répertoires).

Chart Helm : Envoy Gateway remplace NGINX Ingress

Pour les déploiements Kubernetes via le chart Helm, le contrôleur NGINX Ingress intégré est remplacé par défaut par la Gateway API avec Envoy Gateway. Trois options : migrer vers Envoy Gateway, utiliser un contrôleur géré à l'extérieur, ou réactiver explicitement le NGINX intégré, qui reste disponible jusqu'à GitLab 20.0.

Chart Helm et Operator : fin des services intégrés

PostgreSQL, Redis et MinIO ne sont plus intégrés au chart Helm et à l'Operator. Ils doivent être migrés vers des services externes avant la mise à jour, selon le guide de migration de GitLab. Les installations par paquet Linux ne sont pas concernées pour Redis et PostgreSQL.

Les changements à impact moyen

Changement Concerne Action
Fin des paquets Linux pour Ubuntu 20.04 Auto-hébergé Passer en Ubuntu 22.04 ou un autre système supporté avant 19.0
Fin des paquets Linux pour SUSE (openSUSE Leap 15.6, SLES 12.5, SLES 15.6) Auto-hébergé Passer à un déploiement Docker sur la même distribution
Redis 6 n'est plus supporté (Redis externe) Auto-hébergé Redis 7.0+ ou Valkey 7.2 (7.2 recommandé)
Mattermost n'est plus intégré au paquet Linux Auto-hébergé Migrer vers un Mattermost autonome
Auto DevOps : heroku/builder:22 remplacé par heroku/builder:24 Toutes offres Vérifier la compatibilité des builds ; variable AUTO_DEVOPS_BUILD_IMAGE_CNB_BUILDER pour garder l'ancien 
cat /etc/os-release | grep -E '^(NAME|VERSION)='

Affiche le système et sa version : si vous êtes en Ubuntu 20.04, la mise à jour du système d'exploitation doit précéder celle de GitLab.

Les changements à faible impact

  • Spamcheck retiré du paquet Linux et du chart Helm (à déployer séparément avec Docker si utilisé).
  • Commandes slash Slack supprimées : passer à l'application GitLab for Slack.
  • Import Bitbucket Cloud par API : les mots de passe d'application ne sont plus acceptés, il faut des jetons d'API Atlassian.
  • Onglet Tendances (Trending) supprimé de l'exploration des projets, ainsi que l'argument GraphQL trending.
  • Registre de conteneurs : les pilotes de stockage azure et s3 deviennent des alias de azure_v2 et s3_v2 ; pour S3, Signature Version 4 devient obligatoire.

Ce qui change pour vos pipelines CI/CD

Deux suppressions concernent l'automatisation autour des jetons de job CI/CD :

  • la mutation GraphQL ciJobTokenScopeAddProject est supprimée : utilisez ciJobTokenScopeAddGroupOrProject ;
  • l'attribut ci_job_token_scope_enabled disparaît de l'API REST Projects : la gestion de l'accès des jetons de job se fait dans les paramètres CI/CD du projet.
grep -rn "ciJobTokenScopeAddProject\|ci_job_token_scope_enabled" .

À lancer à la racine de vos dépôts d'outillage (scripts, Terraform, modules d'automatisation) pour trouver les usages à corriger.

Méthode de mise à jour

  1. Passer par 18.11, dernière version de la branche 18, en suivant le chemin indiqué par l'outil GitLab Upgrade Path. Les montées de version majeure imposent des étapes intermédiaires.
  2. Laisser se terminer les migrations en arrière-plan avant chaque nouvelle étape (Admin > Monitoring > Background migrations).
  3. Mettre à jour PostgreSQL en 17 et, si besoin, le système d'exploitation.
  4. Corriger les usages des fonctionnalités supprimées (ROPC, API des jetons de job, Bitbucket…).
  5. Tester en préproduction, puis passer en 19.x, directement sur la dernière version corrective de la branche.

En octobre 2026, deux failles critiques ont été corrigées sur les branches 18.11 à 19.5. Quelle que soit votre branche, installez la dernière version corrective : voir notre article sur la faille CVE-2026-110264.

Checklist

  • Système d'exploitation supporté (plus d'Ubuntu 20.04 ni de SUSE pour les paquets Linux).
  • PostgreSQL 17 en place, espace disque vérifié.
  • Redis externe en 7.0+ ou Valkey 7.2.
  • Aucune intégration n'utilise le flux OAuth ROPC.
  • Automatisations CI/CD mises à jour (ciJobTokenScopeAddGroupOrProject).
  • Chart Helm : choix du contrôleur d'entrée et services externes (PostgreSQL, Redis, stockage objet).
  • Mattermost et Spamcheck migrés s'ils sont utilisés.
  • Passage par 18.11, migrations en arrière-plan terminées.
  • Tests en préproduction, puis mise à jour vers la dernière version corrective 19.x.

FAQ

Puis-je passer directement de 18.x à 19.x ? Pas toujours : selon votre version de départ, des étapes intermédiaires sont obligatoires. L'outil officiel GitLab Upgrade Path indique le chemin exact.

Je suis sur GitLab.com. Suis-je concerné ? Les changements côté serveur sont appliqués par GitLab. Les suppressions d'API (ROPC, jetons de job, Bitbucket, tendances) vous concernent en revanche si vos scripts ou intégrations les utilisent.

Je suis en Ubuntu 20.04 et je ne peux pas mettre à jour le système rapidement. Que faire ? GitLab 18.11 est la dernière version disponible pour ce système. C'est une impasse : planifiez la mise à jour vers Ubuntu 22.04 ou une migration vers un déploiement Docker.

Faut-il mettre à jour GitLab Runner en même temps ? Le runner se met à jour séparément. Gardez-le sur une version compatible avec votre version de GitLab, idéalement la même branche majeure et mineure.

Conclusion

GitLab 19 demande moins d'adaptations que les versions majeures précédentes, mais celles qui restent sont structurantes. Avec les correctifs de sécurité désormais concentrés sur les branches récentes, rester bloqué en 18.x a un coût réel.

  1. Vérifiez le socle : système d'exploitation, PostgreSQL 17, Redis.
  2. Cherchez les usages des API supprimées dans vos scripts et intégrations.
  3. Suivez le chemin de mise à jour officiel et visez la dernière version corrective.

Sources officielles