Ressources · Intégration n8n

Intégration GitLab n8nAutomatiser GitLab avec n8n.

Ce qui se passe dans tes dépôts n'a aucune raison de rester dans tes dépôts. Une intégration GitLab n8n expose 18 opérations réparties sur 5 ressources : fichiers, issues, releases, dépôts et utilisateurs. Le GitLab Trigger écoute 12 types d'événements et réagit en quelques secondes.

Tester l'intégration GitLab sur n8nVoir les 18 opérations

Avis vérifiés sur Trustpilot · Agence IA, automatisation & growth

Pourquoi automatiser

À quoi sert une intégration GitLab n8n ?

Une intégration GitLab n8n relie tes dépôts à tout ce qui gravite autour. Le nœud GitLab appelle l'API de GitLab à ta place : un workflow lit un fichier, ouvre une issue ou publie une release sans que personne n'ouvre l'interface. Le GitLab Trigger fait le trajet inverse. Il enregistre un webhook, c'est-à-dire une URL n8n que GitLab appelle dès qu'il se passe quelque chose dans le projet.

Premier scénario : les notes de version qui s'écrivent seules. Un tag arrive, le trigger part sur tag_push, le nœud enchaîne release.create avec ce tag et une description construite en amont, et l'annonce tombe dans Slack avant que quiconque ait rafraîchi une page.

Deuxième scénario : le tri des tickets qui ne dépend plus de la vigilance d'une personne. repository.getIssues récupère chaque matin les issues ouvertes, filtre sur un label, et dépose la liste dans Google Sheets pour la revue hebdo. Ajoute issue.edit et les tickets dormants se ferment sur une règle, pas sur une humeur.

Troisième scénario : le dépôt comme fichier de configuration. file.get lit un JSON sur la branche par défaut, le workflow s'en sert, puis file.create réécrit le résultat avec un message de commit qui dit d'où il vient. Les équipes qui gardent aussi un miroir sur GitHub rejouent le même montage des deux côtés.

Quand l'opération n'existe pas dans le nœud, le repli s'appelle HTTP Request. Le nœud GitLab couvre les fichiers, les issues, les releases, les dépôts et les utilisateurs. Le reste de l'API GitLab reste accessible : le nœud HTTP Request tape l'endpoint directement et réutilise le même credential GitLab, cet identifiant enregistré une fois dans n8n, via l'authentification prédéfinie.

Deux limites à connaître avant de construire. Les opérations de release demandent un Project ID, l'identifiant ou le chemin encodé du projet, alors que les fichiers et les issues demandent un Project Owner : un même workflow jongle donc avec les deux conventions. Et les listes reviennent paginées : si Return All reste décoché, n8n s'arrête à Limit. Si le choix de plateforme n'est pas tranché, l'Avis n8n traite le sujet, et la Formation n8n va plus loin sur les expressions.

Connexion

Comment connecter GitLab à n8n ?

  1. 01

    Créer un jeton d'accès dans GitLab

    Dans GitLab, clique sur ton avatar, puis Edit profile, puis Access tokens dans la barre latérale, puis Add new token. Donne-lui un Name du genre n8n integration, renseigne une expiry date, et choisis tes Scopes. Le scope api ouvre d'un coup tout ce que sait faire le nœud ; des scopes plus fins conviennent une fois que tu sais quelles opérations tournent vraiment.

  2. 02

    Enregistrer le credential dans n8n

    Ouvre le menu Credentials de n8n et crée un credential GitLab. Colle le jeton dans Access Token, puis renseigne GitLab Server avec l'URL de ton instance : ça compte dès que l'équipe héberge GitLab elle-même au lieu de passer par gitlab.com. Un credential se crée une fois et se réutilise partout. Le nœud GitLab comme le GitLab Trigger vont le chercher dans une liste déroulante.

  3. 03

    Ou déclarer une application OAuth2

    OAuth2 est la méthode recommandée. Dans GitLab, va dans Edit profile, puis Applications, puis Add new application. Recopie l'OAuth Redirect URL affichée par n8n dans le champ Redirect URI de GitLab, coche les mêmes Scopes, et enregistre. GitLab renvoie alors un Application ID et un Secret, qui deviennent Client ID et Client Secret côté n8n.

Déclencheurs

Quels événements GitLab peuvent lancer un workflow ?

GitLab Trigger est le nœud qui démarre un workflow quand quelque chose se passe dans GitLab. Il écoute 12 événements, listés ci-dessous par famille. Tu en choisis un ou plusieurs, tu actives le workflow : n8n enregistre le webhook (l'URL que GitLab appelle) sur ton compte.

Ce que tu vois dans n8n

Tous les événements, par famille

Une ligne par objet, une puce par action. L'événement à cocher dans le nœud s'écrit objet.action ; survole une puce pour lire quand il se déclenche.

confidential_issues.*1
  • confidential_issues.
    • confidential_issues
confidential_note.*1
  • confidential_note.
    • confidential_note
deployment.*1
  • deployment.
    • deployment
issues.*1
  • issues.
    • issues
job.*1
  • job.
    • job
merge_requests.*1
  • merge_requests.
    • merge_requests
note.*1
  • note.
    • note
pipeline.*1
  • pipeline.
    • pipeline
push.*1
  • push.
    • push
releases.*1
  • releases.
    • releases
tag_push.*1
  • tag_push.
    • tag_push
wiki_page.*1
  • wiki_page.
    • wiki_page

Le trigger accepte aussi * (tout événement). Pratique pour du log, dangereux en production.

Notes de configuration

01Configure the GitLab TriggerLe trigger a besoin de savoir quel projet surveiller et quoi écouter. Rien de plus.

Le trigger a besoin de savoir quel projet surveiller et quoi écouter. Rien de plus.

Paramètres clés

  • Repository Owner : l'utilisateur, le groupe ou le namespace auquel appartient le projet.
  • Repository Name : le nom du dépôt lui-même.
  • Events : la liste que tu coches. Une entrée joker, *, s'abonne à tous les événements d'un coup, pratique tant que tu cherches encore ce qui t'intéresse.
Quand l'utiliser
à l'activation du workflow, n8n enregistre un webhook auprès de GitLab. Autrement dit, GitLab appelle une URL n8n à chaque événement, et la charge utile arrive en quelques secondes, sans polling ni intervalle à régler. Commence avec le joker sur un projet de test, regarde ce qui tombe vraiment, puis resserre sur les deux ou trois événements que tu gardes.
02Push, Tag and Merge Request eventsCes trois-là portent le mouvement quotidien du code.

Ces trois-là portent le mouvement quotidien du code.

Paramètres clés

  • Push (push) : part quand tu pousses sur le dépôt, sauf quand le push concerne un tag.
  • Tag (tag_push) : part quand tu crées ou supprimes des tags, le point d'accroche propre pour tout ce qui ressemble à une version.
  • Merge Request (merge_requests) : part quand une merge request est créée, mise à jour, fusionnée ou fermée, et aussi quand un commit s'ajoute sur la branche source.
Quand l'utiliser
la fusion sur la branche principale reste le moment où une équipe veut un effet de bord, qu'il s'agisse de fermer l'issue liée avec issue.edit ou de résumer le changement là où traînent les relecteurs. Comme push reste muet sur les tags, tu peux traiter les commits et les versions dans deux workflows séparés.
03Pipeline, Job and Deployment eventsCôté CI, GitLab raconte lui-même son avancement.

Côté CI, GitLab raconte lui-même son avancement.

Paramètres clés

  • Pipeline (pipeline) : part à chaque changement de statut d'un pipeline.
  • Job (job) : part à chaque changement de statut d'un job, donc un seul pipeline en produit plusieurs.
  • Deployments (deployment) : part quand un déploiement démarre, réussit, échoue ou est annulé.
  • Release (releases) : part quand une release est créée ou mise à jour.
Quand l'utiliser
un build de nuit qui échoue sans que personne le lise, c'est un build qui part quand même en production. Écoute pipeline, filtre sur le statut contenu dans la charge utile, et envoie les échecs là où les gens regardent déjà. Garde job pour les cas où il te faut l'étape fautive par son nom : c'est nettement plus bavard. Quant à deployment, c'est celui à prendre quand la question porte sur l'environnement plutôt que sur le build, puisqu'il remonte aussi les annulations.
04Issue, Comment and Wiki Page eventsTout ce que les humains écrivent autour du code a son propre événement.

Tout ce que les humains écrivent autour du code a son propre événement.

Paramètres clés

  • Issue (issues) : part quand une issue est créée, mise à jour, fermée ou rouverte.
  • Comment (note) : part sur un nouveau commentaire, qu'il soit posé sur un commit, une merge request, une issue ou un extrait de code.
  • Confidential Issues et Confidential Comments (confidential_issues, confidential_note) : les mêmes signaux pour les issues et les commentaires confidentiels, volontairement séparés.
  • Wiki Page (wiki_page) : part quand une page de wiki est créée, modifiée ou supprimée.
Quand l'utiliser
les équipes support vivent sur issues, parce qu'un nouveau ticket ouvre un processus qui continue loin de GitLab. Ne t'abonne aux variantes confidentielles que si le workflow a le droit de manipuler ce contenu : les événements standards ne les couvrent pas.
Actions

Ce que le nœud GitLab sait faire

Le nœud GitLab expose 18 opérations sur 5 ressources. Pour chacune : le nœud tel que tu le configures dans n8n, les champs obligatoires, et nos notes de terrain.

Matrice ressources × opérations
RessourceCreateGetGet ManyUpdateDeleteCreate CommentEditGet IssuesGet RepositoriesListLock
File✓✓✓✓✓
Issue✓✓✓✓✓
Release✓✓✓✓✓
Repository✓✓
User✓

File

5 opérations
01

Create a file

file.create

Ce que tu vois dans n8n

Notes & cas d'usage

Commite un nouveau fichier dans le dépôt, sur la branche que tu indiques, exactement comme le ferait un développeur.

Paramètres clés

  • Project Owner : l'utilisateur, le groupe ou le namespace du projet, par exemple n8n-io.
  • Binary File : décoché, n8n écrit le texte saisi dans File Content ; coché, il prend le fichier dans Input Binary Field, le champ binaire entrant désigné par son nom.
  • Commit Message et Branch : le message enregistré avec le commit, et la branche qui le reçoit.
  • File Path : le chemin complet, du type docs/README.md, ou vide pour la racine.
Cas d'usage
renvoyer un changelog généré dans le dépôt à la fin d'un workflow de publication.
02

Delete a file

file.delete

Ce que tu vois dans n8n

Notes & cas d'usage

Supprime un fichier et enregistre la suppression sous forme de commit : l'historique en garde la trace.

Paramètres clés

  • File Path : le chemin complet du fichier à retirer, ou vide pour viser la racine.
  • Branch : la branche sur laquelle le commit de suppression est ajouté.
  • Commit Message : ce que l'historique affichera, c'est-à-dire la seule explication qu'aura un relecteur six mois plus tard.
  • Project Owner : l'utilisateur, le groupe ou le namespace du projet.
Cas d'usage
nettoyer les fichiers d'export temporaires qu'un workflow planifié a déposés la semaine précédente.
03

Edit a file

file.edit

Ce que tu vois dans n8n

Notes & cas d'usage

Remplace le contenu d'un fichier déjà présent et commite la nouvelle version.

Paramètres clés

  • File Content : le nouveau texte, qui écrase l'ancien au lieu de s'ajouter à la suite.
  • Binary File : coche-le pour pousser le fichier depuis Input Binary Field plutôt qu'un texte saisi.
  • File Path, Branch et Commit Message : quel fichier change, où, et sous quel message.
  • Project Owner : l'utilisateur, le groupe ou le namespace du projet.
Cas d'usage
tenir à jour un fichier de versions après un déploiement, sans qu'un humain édite une ligne à la main.
04

Get a file

file.get

Ce que tu vois dans n8n

Notes & cas d'usage

Relit un fichier du dépôt pour que la suite du workflow travaille sur son contenu.

Paramètres clés

  • Put Output File in Field : le nom du champ binaire de sortie dans lequel n8n dépose le fichier.
  • As Binary Property : coché, tu récupères un champ binaire ; décoché, tu reçois la réponse brute de l'API.
  • Reference, dans Additional Parameters : le commit, la branche ou le tag à lire, par exemple main. Laissé vide, GitLab prend la branche par défaut du dépôt.
Cas d'usage
charger un fichier JSON de paramètres versionné dans le dépôt et piloter les branches du workflow avec.
05

List files

file.list

Ce que tu vois dans n8n

Notes & cas d'usage

Liste le contenu d'un dossier du dépôt, un item par entrée trouvée.

Paramètres clés

  • File Path : le dossier à lister, vide pour la racine.
  • Return All : coché, n8n parcourt toutes les pages de résultats ; décoché, il s'arrête à Limit, et Page te permet d'aller chercher une page précise.
  • Recursive, dans Additional Parameters : coché, tu obtiens tout l'arbre sous le chemin au lieu d'un seul niveau.
  • Reference : le commit, la branche ou le tag à lister.
Cas d'usage
inventorier les documents présents sous un dossier de doc avant de générer un sommaire.

Issue

5 opérations
06

Create an issue

issue.create

Ce que tu vois dans n8n

Notes & cas d'usage

Ouvre une nouvelle issue dans le projet et la renvoie, numéro compris, aux nœuds suivants.

Paramètres clés

  • Title : le titre de l'issue, seul champ obligatoire en plus du projet.
  • Body : la description, souvent construite depuis l'item entrant avec une expression du type {{ $json.message }}.
  • Due Date et Assignees : une échéance, et les personnes qui la portent.
  • Label et Assignee, dans la collection Labels : un label à poser, et un identifiant d'utilisateur à qui attribuer l'issue.
Cas d'usage
transformer un formulaire de support en bug suivi, avec l'email du demandeur dans le corps.
07

Create a comment on an issue

issue.createComment

Ce que tu vois dans n8n

Notes & cas d'usage

Ajoute un commentaire sur une issue existante, ce qui garde la conversation là où l'équipe la lit déjà.

Paramètres clés

  • Issue Number : le numéro de l'issue qui reçoit le commentaire, en général repris d'un nœud précédent avec {{ $json.iid }}.
  • Body : le texte du commentaire.
  • Project Owner : l'utilisateur, le groupe ou le namespace du projet.
Cas d'usage
poster le résultat d'un déploiement sur l'issue qui l'a déclenché, pour que le fil porte aussi le résultat et pas seulement la demande.
08

Edit an issue

issue.edit

Ce que tu vois dans n8n

Notes & cas d'usage

Met à jour une issue existante, en ne changeant que les champs ajoutés dans la collection.

Paramètres clés

  • Issue Number : quelle issue est modifiée.
  • State, dans Edit Fields : closed ou open, ce qui permet à un workflow de fermer un ticket tout seul.
  • Title, Body, Labels, Assignees et Due Date : tout le reste que la collection autorise à réécrire.
Cas d'usage
fermer l'issue liée dès que la merge request qui la corrige est fusionnée sur la branche principale.
09

Get an issue

issue.get

Ce que tu vois dans n8n

Notes & cas d'usage

Récupère une issue précise et renvoie ses données, sans rien modifier dans GitLab.

Paramètres clés

  • Issue Number : le numéro de l'issue à lire.
  • Project Owner : l'utilisateur, le groupe ou le namespace du projet.
Cas d'usage
enrichir une alerte avant de l'envoyer. Le trigger te donne un numéro, cette opération te donne le titre, l'état, les labels et les assignés, et le message qui part à l'équipe dit enfin quelque chose au lieu de pointer un identifiant.
10

Lock an issue

issue.lock

Ce que tu vois dans n8n

Notes & cas d'usage

Verrouille la discussion d'une issue : plus aucun commentaire ne peut s'ajouter au fil.

Paramètres clés

  • Issue Number : l'issue à verrouiller.
  • Lock Reason : au choix off-topic, too heated, resolved ou spam, ce qui consigne pourquoi le fil a été gelé.
Cas d'usage
un projet public attire des commentaires sur des sujets tranchés depuis longtemps. Un workflow planifié relit les issues fermées, les verrouille avec resolved, et les mainteneurs arrêtent de répondre à la même question.

Release

5 opérations
11

Create a release

release.create

Ce que tu vois dans n8n

Notes & cas d'usage

Publie une release sur le projet, rattachée à un tag, et la renvoie.

Paramètres clés

  • Tag : le tag de la release, seul champ requis en plus du projet.
  • Ref, dans Additional Fields : si le tag n'existe pas encore, GitLab crée la release à partir de cette référence, un SHA de commit, un autre nom de tag ou un nom de branche.
  • Name et Description : le nom affiché de la release et ses notes.
Cas d'usage
publier la version depuis le workflow qui a déjà construit le livrable, avec des notes assemblées à partir des issues fermées.
12

Delete a release

release.delete

Ce que tu vois dans n8n

Notes & cas d'usage

Supprime une release du projet. Le tag Git, lui, reste un objet distinct de la release.

Paramètres clés

  • Project ID : l'identifiant ou le chemin encodé du projet, que les opérations de release utilisent à la place d'un simple propriétaire.
  • Tag Name : le tag Git auquel la release est associée.
  • Project Owner : l'utilisateur, le groupe ou le namespace du projet.
Cas d'usage
annuler une release qu'un pipeline a publiée depuis la mauvaise branche, avant que quelqu'un la télécharge.
13

Get a release

release.get

Ce que tu vois dans n8n

Notes & cas d'usage

Renvoie une release, identifiée par son tag, avec les données telles que GitLab les stocke.

Paramètres clés

  • Tag Name : le tag Git auquel la release est associée.
  • Project ID : l'identifiant ou le chemin encodé du projet.
  • Project Owner : l'utilisateur, le groupe ou le namespace du projet.
Cas d'usage
vérifier que la release existe avant qu'un workflow de déploiement continue, et arrêter l'exécution proprement plutôt que de pousser une version jamais publiée.
14

Get many releases

release.getAll

Ce que tu vois dans n8n

Notes & cas d'usage

Renvoie les releases d'un projet sous forme de liste, un item par release.

Paramètres clés

  • Return All : coché, n8n parcourt tout l'historique ; décoché, il s'arrête à Limit.
  • Order By, dans Additional Fields : created_at ou released_at, deux dates qui diffèrent dès qu'une release est préparée à l'avance.
  • Sort : asc ou desc pour le sens du tri.
Cas d'usage
reconstituer l'historique des mises en production du trimestre, trié sur la date de publication, et l'envoyer dans le tableau que l'équipe produit relit.
15

Update a release

release.update

Ce que tu vois dans n8n

Notes & cas d'usage

Modifie une release déjà publiée, sans toucher au tag sur lequel elle pointe.

Paramètres clés

  • Tag Name : quelle release est mise à jour.
  • Description, dans Additional Fields : les notes de la release, où le Markdown est accepté.
  • Milestones : le titre de chaque jalon à associer, sous forme de liste de titres séparés par des virgules.
  • Released At : la date à laquelle la release est ou était prête.
  • Name : le nom de la release.
Cas d'usage
compléter une release avec les notes de migration une fois que l'équipe ops les a validées.

Repository

2 opérations
16

Get a repository

repository.get

Ce que tu vois dans n8n

Notes & cas d'usage

Renvoie les données d'un dépôt, et ne demande rien d'autre que le projet lui-même.

Paramètres clés

  • Project Owner : l'utilisateur, le groupe ou le namespace du projet, par exemple n8n-io.
Cas d'usage
résoudre un dépôt en début d'exécution. Un seul nœud te rend les identifiants et la branche par défaut, et les opérations suivantes cessent de deviner sur quelle branche elles sont censées écrire.
17

Get issues of a repository

repository.getIssues

Ce que tu vois dans n8n

Notes & cas d'usage

Renvoie les issues d'un dépôt, filtrées côté serveur plutôt que dans un nœud plus loin.

Paramètres clés

  • State, dans Filters : opened, closed, ou vide pour tous les états.
  • Labels, Assignee, Creator et Search : restreindre par liste de labels, par nom d'utilisateur, ou sur le titre et la description.
  • Updated After : seulement les issues touchées à partir d'une date, la base d'un récapitulatif quotidien.
  • Return All et Limit : la liste entière, ou une liste plafonnée.
Cas d'usage
chaque lundi, sortir les issues modifiées sur les 7 derniers jours et publier le récapitulatif.

User

1 opération
18

Get a user's repositories

user.getRepositories

Ce que tu vois dans n8n

Notes & cas d'usage

Renvoie les dépôts d'un utilisateur, d'un groupe ou d'un namespace, un item par dépôt.

Paramètres clés

  • Project Owner : l'utilisateur, le groupe ou le namespace dont tu veux les dépôts, par exemple n8n-io.
Cas d'usage
alimenter une boucle. Tu listes les dépôts du namespace de l'équipe, tu rejoues la même opération fichier ou issue sur chacun, et la règle s'applique à tout le namespace au lieu du seul dépôt auquel quelqu'un a pensé.
Besoin d'aide

Besoin d'aide pour automatiser GitLab avec n8n ?

L'équipe te répond directement.

Chaque message est lu par une personne.

FAQ

GitLab et n8n : les questions qui suivent

01L'intégration GitLab est-elle gratuite dans n8n ?
Oui. Le nœud GitLab et le GitLab Trigger sont livrés avec n8n : rien à installer, aucun coût supplémentaire côté n8n. C'est vrai sur n8n Cloud, l'offre hébergée par n8n, comme sur une instance auto-hébergée en Community Edition sous licence Sustainable Use. Un workflow se comporte de la même façon dans les deux cas, donc tu peux prototyper d'un côté et faire tourner de l'autre. Ce que coûte GitLab lui-même dépend de ton propre plan et sort du périmètre de n8n. La seule chose que l'automatisation ajoute, c'est le temps d'exécution des workflows que tu décides de lancer.
02Quels credentials ou quels droits faut-il pour GitLab ?
Deux méthodes existent, et toutes les deux authentifient aussi bien le nœud que le trigger. La première est le jeton d'accès API : tu le crées dans Edit profile, puis Access tokens, et tu le renseignes dans n8n avec l'URL de ton GitLab Server, un champ qui compte dès que l'instance est auto-hébergée. La seconde est OAuth2, la méthode recommandée : tu déclares une application dans GitLab, tu recopies l'OAuth Redirect URL affichée par n8n dans le champ Redirect URI, puis l'Application ID et le Secret deviennent Client ID et Client Secret. Côté droits, le scope api couvre toutes les opérations du nœud ; prends plus fin si tu sais exactement ce qui tourne.
03Quelles sont les limites d'une intégration GitLab n8n ?
Le nœud couvre 5 ressources, fichiers, issues, releases, dépôts et utilisateurs, pour 18 opérations au total. Tout ce qui sort de cette liste, et l'API GitLab est bien plus large, passe par le nœud HTTP Request, qui appelle l'endpoint directement en réutilisant le même credential GitLab. Deux détails piègent régulièrement. Les listes sont paginées : sans Return All, le nœud s'arrête à Limit et tu perds des lignes sans t'en rendre compte. Et les opérations de release identifient le projet par Project ID, l'identifiant ou le chemin encodé, là où les fichiers et les issues passent par Project Owner : un workflow transporte donc souvent les deux valeurs.
04Le GitLab Trigger réagit-il en temps réel ?
Oui, il fonctionne par webhook. Quand tu actives le workflow, n8n enregistre une URL de webhook auprès de GitLab, et GitLab appelle cette URL à chaque événement auquel tu t'es abonné : la charge utile arrive donc en quelques secondes. Il n'y a ni boucle de polling ni intervalle à régler, ce qui implique aussi qu'un workflow désactivé ne reçoit rien du tout. Tu choisis ce qui arrive avec le paramètre Events, parmi 12 types d'événements qui couvrent les pushes, les tags, les merge requests, les pipelines, les jobs, les déploiements, les releases, les issues, les commentaires et les pages de wiki. Une entrée joker s'abonne à tout d'un coup.
05n8n ou Make pour automatiser GitLab ?
Ça dépend d'où sont tes contraintes. Make est hébergé uniquement et facturé à l'opération : c'est prévisible à faible volume, et ça grimpe avec chaque étape ajoutée dans un scénario. n8n tourne sur son propre Cloud ou sur tes serveurs, donc un workflow qui manipule du code source peut rester dans ton réseau, et le coût suit l'instance plutôt que le nombre d'opérations. Make propose un éditeur visuel que beaucoup d'équipes lisent plus vite d'un coup d'œil. Sur GitLab en particulier, le critère qui tranche reste la maîtrise des données : le code, les tickets et les notes de version sont rarement ce qu'une équipe veut faire transiter en premier par un tiers.
Même plateforme

Autres docs utiles sur ce stack.

Voir toutes les intégrations