Connecter GitLab à n8n : automatiser issues, merge requests et pipelines

GitLab embarque déjà sa propre CI/CD, ses boards et ses webhooks — pour ce qui se passe dans GitLab. Mais dès que l'information doit en sortir (prévenir l'équipe sur Slack quand un pipeline casse, trier les issues entrantes avec un LLM, alimenter un board de gestion de projet), on se retrouve à tordre .gitlab-ci.yml pour faire de l'orchestration métier, alors que n8n est exactement conçu pour cela. Ce guide couvre l'authentification par token, les opérations réelles du node GitLab, le GitLab Trigger, puis trois automatisations concrètes — dont un triage d'issues par IA et une alerte pipeline enrichie d'un résumé du log d'erreur.

C'est le pendant GitLab de notre guide d'automatisation GitHub avec n8n, avec une différence de taille : GitLab s'auto-héberge couramment, et le couple GitLab + n8n self-hosted garde code et automatisations sur votre infrastructure.

Authentification : personal access token et champ Server URL

Le credential GitLab de n8n propose deux méthodes : API Access Token et OAuth2.

Pour un usage backend classique, le personal access token est le choix par défaut :

1. Dans GitLab : avatar → Edit profile → Access tokens → Add new token ;
2. Choisissez les scopes : api couvre toutes les fonctionnalités du node (lecture-écriture). Pour un workflow qui ne fait que lire, read_api ou read_repository réduisent la surface d'exposition ;
3. Fixez une date d'expiration et notez-la — un token qui expire en silence est une panne pénible à diagnostiquer ;
4. Dans n8n : credential GitLab API, deux champs — Server URL et le token.

Le champ Server URL est la clé de l'angle self-hosted : indiquez https://gitlab.com pour le SaaS, ou l'URL de votre instance (https://gitlab.mondomaine.fr) pour une installation auto-hébergée. Rien d'autre ne change : node et trigger fonctionnent à l'identique. Si vous hébergez les deux, code source, issues et workflows d'automatisation restent intégralement sur vos serveurs — un argument de cohérence pour les équipes qui ont déjà tranché le débat self-hosted vs cloud pour n8n côté souveraineté. Dans tous les cas, le token vit dans les credentials chiffrés de n8n : les règles de notre guide de sécurisation des credentials API s'appliquent.

OAuth2 (création d'une Application dans GitLab, Client ID + Secret) se réserve aux cas où chaque utilisateur connecte son propre compte.

Les opérations du node GitLab

Le node couvre cinq ressources — moins étendues que le node GitHub, autant le savoir d'emblée :

• Issue : Create, Get, Edit (titre, description, labels, assignés, état), Lock, Create Comment — la matière première du triage ;
• File : Create, Get, Edit, Delete, List — chaque écriture produit un commit, la brique de la sauvegarde automatique de vos workflows n8n dans Git si votre remote est GitLab ;
• Release : Create, Get, Get All, Update, Delete — pour générer et publier des notes de version ;
• Repository : Get (métadonnées du projet) et Get Issues (liste des issues du dépôt, avec filtres) ;
• User : Get Repositories — les projets d'un utilisateur donné.

Absence notable : pas de ressource Merge Request en écriture. Le GitLab Trigger reçoit bien les événements MR (voir ci-dessous), mais pour créer, commenter, approuver ou fusionner une merge request, il faut passer par un node HTTP Request vers l'API REST de GitLab (/projects/:id/merge_requests), avec le même token dans un header PRIVATE-TOKEN. Même chose pour les pipelines (relancer un job, télécharger un log) : l'API REST prolonge naturellement le node.

GET https://gitlab.mondomaine.fr/api/v4/projects/42/jobs/{{ $json.build_id }}/trace
Header : PRIVATE-TOKEN = {{ votre credential Header Auth }}

Le GitLab Trigger : douze événements en temps réel

Le GitLab Trigger enregistre automatiquement un webhook sur le projet à l'activation du workflow, pour les événements cochés : Push, Issue, Merge Request, Pipeline, Job, Tag, Release, Comment, Deployments, Wiki page, plus les variantes confidentielles (Confidential Issues, Confidential Comments). GitLab pousse chaque événement immédiatement, avec un payload riche : object_kind indique le type d'événement, object_attributes porte le détail (statut du pipeline, action sur l'issue, branches source et cible d'une MR…).

Deux points d'attention. D'abord, votre instance n8n doit être joignable par GitLab : en HTTPS public pour gitlab.com, ou simplement sur le même réseau privé si GitLab et n8n tournent tous deux chez vous. Ensuite, le trigger transmet tous les événements du type coché : un événement Pipeline part à chaque changement de statut (pending, running, success, failed). Un node IF juste après le trigger fait le tri :

{{ $json.object_attributes.status === "failed" }}

Trois automatisations à fort rendement

1. Triage d'issues entrantes par IA

GitLab Trigger sur l'événement Issue → un IF ne garde que object_attributes.action === "open" → un node AI Agent (voir notre guide du node AI Agent) lit titre et description, propose des labels (bug, feature, question), une priorité, et repère les informations manquantes → le node GitLab (Issue → Edit) applique les labels, puis (Issue → Create Comment) demande poliment version et étapes de reproduction si elles manquent.

Ce dernier point n'est pas un gadget : l'étude de Nicolas Bettenburg, Thomas Zimmermann et leurs coauteurs, « What Makes a Good Bug Report? » (FSE 2008, voir sur Google Scholar), fondée sur 466 réponses de développeurs d'Apache, Eclipse et Mozilla, a mis en évidence un décalage systématique entre ce dont les développeurs ont besoin (étapes de reproduction, stack traces, cas de test) et ce que les rapporteurs fournissent spontanément. Un agent qui réclame ces éléments dès l'ouverture de l'issue comble exactement ce décalage, avant que l'issue ne vieillisse dans la file.

2. Alerte Slack enrichie sur pipeline échoué

GitLab Trigger sur Pipeline → IF sur status === "failed" → un HTTP Request récupère le log du job échoué via l'API (/jobs/:id/trace) → un LLM en extrait un résumé de trois lignes : l'étape qui a cassé, l'erreur probable, la première piste → un node Slack poste le tout avec le lien direct vers le pipeline, la branche et l'auteur du commit (notre guide du bot Slack IA pour la mise en forme).

L'enjeu est réel : l'analyse de Moritz Beller, Georgios Gousios et Andy Zaidman, « Oops, My Tests Broke the Build » (MSR 2017, voir sur Google Scholar), portant sur plus de 2,6 millions de builds CI de projets GitHub, a montré que l'échec des tests est la première cause de builds cassés. Un résumé qui dit quoi a cassé, plutôt qu'une notification générique, fait gagner le premier quart d'heure de diagnostic. Le même pattern s'applique aux erreurs applicatives avec notre triage d'alertes Sentry par IA.

3. Synchronisation des issues vers un board ou un digest hebdo

Deux variantes. En temps réel : GitLab Trigger sur Issue → création ou mise à jour du ticket correspondant dans Jira ou votre outil de gestion de projet, avec un mapping des identifiants tenu par n8n pour éviter les doublons. En différé : un Schedule Trigger hebdomadaire → GitLab (Repository → Get Issues) récupère les issues ouvertes → un LLM regroupe par thème et signale celles sans réponse depuis plus de sept jours → digest posté sur Slack chaque lundi matin.

Bonnes pratiques et limites

• Filtrez tôt : le trigger Pipeline émet à chaque transition de statut — un IF en tête de workflow évite les exécutions inutiles.
• Attention aux boucles : un workflow qui committe (ressource File) dans le dépôt qu'il surveille en Push se re-déclenche lui-même. Filtrez sur l'auteur du commit ou un marqueur dans le message.
• Les MR passent par l'API REST : ne cherchez pas une opération Merge Request dans le node, elle n'y est pas — HTTP Request avec PRIVATE-TOKEN.
• Testez vos workflows comme du code : versionnez-les et validez-les en CI, comme dans notre guide pour valider ses workflows n8n en intégration continue — la démarche se transpose à GitLab CI.
• Self-hosted des deux côtés : GitLab et n8n auto-hébergés sur le même réseau privé évitent d'exposer le webhook sur Internet.

En résumé

Un personal access token avec le scope api, le champ Server URL pour pointer gitlab.com ou votre instance, le GitLab Trigger pour réagir en temps réel aux push, issues, merge requests et pipelines, et les ressources Issue/File/Release/Repository pour agir — le HTTP Request comblant l'absence d'opérations merge request. Commencez par le triage d'issues par IA et l'alerte pipeline enrichie : deux workflows d'une heure qui font sortir l'information de GitLab au moment exact où elle a de la valeur.