Recursos · Integración n8n

Integración GitLab n8nAutomatiza GitLab con n8n.

Tu repositorio sabe antes que nadie lo que acaba de cambiar en el producto. Una integración GitLab n8n expone 18 operaciones repartidas en 5 recursos: archivos, issues, releases, repositorios y usuarios. El GitLab Trigger escucha 12 tipos de eventos y reacciona en segundos.

Reseñas verificadas en Trustpilot · Agencia de IA, automatización y growth

Por qué automatizar

¿Para qué sirve una integración GitLab n8n?

Una integración GitLab n8n conecta tus repositorios con todo lo que los rodea. El nodo GitLab llama a la API de GitLab por ti: un flujo de trabajo lee un archivo, abre una issue o publica una release sin que nadie entre en la interfaz. El GitLab Trigger hace el camino inverso. Registra un webhook, es decir, una URL de n8n a la que GitLab llama en cuanto pasa algo en el proyecto.

Primer escenario: las notas de versión que se escriben solas. Llega una etiqueta, el trigger salta con tag_push, el nodo ejecuta release.create con esa etiqueta y una descripción preparada antes, y el aviso aterriza en Slack sin que nadie recargue una página.

Segundo escenario: el reporte de incidencias que no depende de que alguien mire el tablero. repository.getIssues recupera cada mañana las issues abiertas, filtra por etiqueta y prepara un resumen que sale por Gmail hacia el responsable del área. Añade issue.edit y los tickets dormidos se cierran por una regla, no por intuición.

Tercer escenario: el repositorio como almacén de configuración. file.get lee un JSON de la rama por defecto, el flujo lo usa, y file.create devuelve el resultado con un mensaje de commit que explica de dónde sale. Los equipos que además mantienen un espejo en GitHub repiten el mismo montaje en los dos lados.

Cuando la operación no está en el nodo, el recambio se llama HTTP Request. El nodo GitLab cubre archivos, issues, releases, repositorios y usuarios. El resto de la API de GitLab sigue disponible: el nodo HTTP Request llama al endpoint directamente y reutiliza el mismo credential de GitLab, esa credencial que se guarda una vez en n8n, mediante la autenticación predefinida.

Dos límites conviene tenerlos claros antes de montar nada. Las operaciones de release piden un Project ID, el identificador o la ruta codificada del proyecto, mientras que archivos e issues piden Project Owner: un mismo flujo convive con las dos convenciones. Y los listados llegan paginados: si Return All queda sin marcar, n8n se detiene en Limit. Si todavía dudas de plataforma, la Reseña n8n entra en ese terreno, y el Curso n8n profundiza en las expresiones.

Conexión

¿Cómo conectar GitLab con n8n?

  1. 01

    Crea un token de acceso en GitLab

    En GitLab, pulsa tu avatar, luego Edit profile, luego Access tokens en la barra lateral, y después Add new token. Ponle un Name del estilo n8n integration, indica una expiry date y elige los Scopes. El scope api concede de golpe todo lo que hace el nodo; los scopes más estrechos funcionan bien cuando ya sabes qué operaciones usas de verdad.

  2. 02

    Guarda la credencial en n8n

    Abre el menú Credentials de n8n y crea una credencial de GitLab. Pega el token en Access Token y rellena GitLab Server con la URL de tu instancia, un detalle que importa en cuanto el equipo aloja GitLab por su cuenta en vez de usar gitlab.com. La credencial se crea una sola vez y se reutiliza en todas partes: tanto el nodo GitLab como el GitLab Trigger la eligen de un desplegable.

  3. 03

    O registra una aplicación OAuth2

    OAuth2 es el método recomendado. En GitLab, entra en Edit profile, luego Applications, y después Add new application. Copia la OAuth Redirect URL que muestra n8n en el campo Redirect URI de GitLab, marca los mismos Scopes y guarda. GitLab devuelve entonces un Application ID y un Secret, que se convierten en Client ID y Client Secret dentro de n8n.

Disparadores

¿Qué eventos de GitLab pueden lanzar un flujo?

GitLab Trigger es el nodo que arranca un workflow cuando algo ocurre en GitLab. Escucha 12 eventos, listados abajo por familia. Eliges uno o varios, activas el workflow y n8n registra el webhook (la URL que GitLab llama) en tu cuenta.

Lo que ves en n8n

Todos los eventos, por familia

Una fila por objeto, un chip por acción. El evento que marcas en el nodo se escribe objeto.acción; pasa el cursor por un chip para leer cuándo se dispara.

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

El trigger también acepta * (cualquier evento). Útil para logs, peligroso en producción.

Notas de configuración

01Configure the GitLab TriggerEl trigger solo necesita saber qué proyecto vigilar y qué escuchar.

El trigger solo necesita saber qué proyecto vigilar y qué escuchar.

Parámetros clave

  • Repository Owner: el usuario, grupo o namespace al que pertenece el proyecto.
  • Repository Name: el nombre del repositorio.
  • Events: la lista que marcas. Una entrada comodín, *, se suscribe a todos los eventos a la vez, útil mientras todavía buscas cuál te interesa.
Cuándo usarlo
al activar el flujo, n8n registra un webhook en GitLab. Dicho de otro modo, GitLab llama a una URL de n8n en cada evento y el contenido llega en segundos, sin polling ni intervalo que ajustar. Empieza con el comodín en un proyecto de prueba, observa qué cae realmente y luego reduce la lista a los dos o tres eventos que te quedas.
02Push, Tag and Merge Request eventsEstos tres recogen el movimiento diario del código.

Estos tres recogen el movimiento diario del código.

Parámetros clave

  • Push (push): salta cuando envías cambios al repositorio, salvo cuando lo que envías es una etiqueta.
  • Tag (tag_push): salta al crear o eliminar etiquetas, el punto de enganche limpio para todo lo que tenga forma de versión.
  • Merge Request (merge_requests): salta cuando una merge request se crea, se actualiza, se fusiona o se cierra, y también cuando se añade un commit a la rama de origen.
Cuándo usarlo
la fusión en la rama principal es el momento en que casi todos los equipos quieren un efecto secundario, ya sea cerrar la issue asociada con issue.edit o resumir el cambio donde están los revisores. Como push guarda silencio con las etiquetas, puedes tratar commits y versiones en dos flujos separados.
03Pipeline, Job and Deployment eventsLa parte de CI de GitLab cuenta ella misma cómo avanza.

La parte de CI de GitLab cuenta ella misma cómo avanza.

Parámetros clave

  • Pipeline (pipeline): salta en cada cambio de estado de un pipeline.
  • Job (job): salta en cada cambio de estado de un job, así que un solo pipeline produce varios.
  • Deployments (deployment): salta cuando un despliegue empieza, termina bien, falla o se cancela.
  • Release (releases): salta cuando una release se crea o se actualiza.
Cuándo usarlo
una compilación nocturna que falla y nadie lee acaba llegando igual a producción. Escucha pipeline, filtra por el estado que viene en el contenido del evento y manda los fallos donde la gente ya mira. Deja job para los casos en los que necesitas el paso fallido por su nombre, porque habla bastante más. Y deployment es el que conviene cuando la pregunta va de entornos y no de compilaciones, porque además informa de las cancelaciones.
04Issue, Comment and Wiki Page eventsTodo lo que las personas escriben alrededor del código tiene su propio evento.

Todo lo que las personas escriben alrededor del código tiene su propio evento.

Parámetros clave

  • Issue (issues): salta cuando una issue se crea, se actualiza, se cierra o se reabre.
  • Comment (note): salta con cada comentario nuevo, esté puesto en un commit, una merge request, una issue o un fragmento de código.
  • Confidential Issues y Confidential Comments (confidential_issues, confidential_note): las mismas dos señales para issues y comentarios confidenciales, separadas a propósito.
  • Wiki Page (wiki_page): salta cuando una página del wiki se crea, se modifica o se elimina.
Cuándo usarlo
los equipos de soporte viven de issues, porque un ticket nuevo abre un proceso que sigue muy lejos de GitLab. Suscríbete a las variantes confidenciales solo si el flujo tiene derecho a manejar ese contenido: los eventos estándar no las cubren.
Acciones

Qué sabe hacer el nodo GitLab

El nodo GitLab expone 18 operaciones en 5 recursos. Para cada una: el nodo tal como lo configuras en n8n, los campos obligatorios y nuestras notas de campo.

Matriz recursos × operaciones
RecursoCreateGetGet ManyUpdateDeleteCreate CommentEditGet IssuesGet RepositoriesListLock
File✓✓✓✓✓
Issue✓✓✓✓✓
Release✓✓✓✓✓
Repository✓✓
User✓

File

5 operaciones
01

Create a file

file.create

Lo que ves en n8n

Notas y casos de uso

Hace commit de un archivo nuevo en el repositorio, en la rama que indiques, igual que lo haría una persona desarrolladora.

Parámetros clave

  • Project Owner: el usuario, grupo o namespace del proyecto, por ejemplo n8n-io.
  • Binary File: sin marcar, n8n escribe el texto de File Content; marcado, toma el archivo de Input Binary Field, el campo binario de entrada indicado por su nombre.
  • Commit Message y Branch: el mensaje que queda en el commit y la rama que lo recibe.
  • File Path: la ruta completa, tipo docs/README.md, o vacía para la raíz.
Casos de uso
devolver al repositorio un changelog generado al final de un flujo de publicación.
02

Delete a file

file.delete

Lo que ves en n8n

Notas y casos de uso

Elimina un archivo y registra la eliminación como un commit, así que el historial conserva el rastro.

Parámetros clave

  • File Path: la ruta completa del archivo que se retira, o vacía para apuntar a la raíz.
  • Branch: la rama donde se añade el commit de eliminación.
  • Commit Message: lo que mostrará el historial, es decir, la única explicación que tendrá quien revise esto medio año después.
  • Project Owner: el usuario, grupo o namespace del proyecto.
Casos de uso
limpiar los archivos de exportación temporales que un flujo programado dejó la semana anterior.
03

Edit a file

file.edit

Lo que ves en n8n

Notas y casos de uso

Sustituye el contenido de un archivo que ya existe y hace commit de la nueva versión.

Parámetros clave

  • File Content: el texto nuevo, que reemplaza al anterior en lugar de añadirse al final.
  • Binary File: márcalo para subir el archivo desde Input Binary Field en vez de un texto escrito.
  • File Path, Branch y Commit Message: qué archivo cambia, dónde y con qué mensaje.
  • Project Owner: el usuario, grupo o namespace del proyecto.
Casos de uso
mantener al día un archivo de versiones después de un despliegue, sin que nadie edite una línea a mano.
04

Get a file

file.get

Lo que ves en n8n

Notas y casos de uso

Vuelve a leer un archivo del repositorio para que el resto del flujo trabaje con su contenido.

Parámetros clave

  • Put Output File in Field: el nombre del campo binario de salida donde n8n deja el archivo.
  • As Binary Property: marcado, recibes un campo binario; sin marcar, recibes la respuesta cruda de la API.
  • Reference, dentro de Additional Parameters: el commit, la rama o la etiqueta que se lee, por ejemplo main. Vacío, GitLab usa la rama por defecto del repositorio.
Casos de uso
cargar un JSON de parámetros versionado en el repositorio y decidir con él por dónde sigue el flujo.
05

List files

file.list

Lo que ves en n8n

Notas y casos de uso

Lista el contenido de una carpeta del repositorio, un item por entrada encontrada.

Parámetros clave

  • File Path: la carpeta que se lista, vacía para la raíz.
  • Return All: marcado, n8n recorre todas las páginas de resultados; sin marcar, se detiene en Limit, y Page te deja pedir una página concreta.
  • Recursive, dentro de Additional Parameters: marcado, obtienes todo el árbol bajo esa ruta en vez de un solo nivel.
  • Reference: el commit, la rama o la etiqueta que se lista.
Casos de uso
revisar qué documentos hay bajo una carpeta de documentación antes de generar un índice.

Issue

5 operaciones
06

Create an issue

issue.create

Lo que ves en n8n

Notas y casos de uso

Abre una issue nueva en el proyecto y la devuelve, número incluido, a los nodos siguientes.

Parámetros clave

  • Title: el título de la issue, el único campo obligatorio además del proyecto.
  • Body: la descripción, muchas veces construida desde el item entrante con una expresión como {{ $json.message }}.
  • Due Date y Assignees: una fecha límite y las personas que la asumen.
  • Label y Assignee, en la colección Labels: una etiqueta que añadir y un ID de usuario al que asignar la issue.
Casos de uso
convertir un formulario de soporte en un bug con seguimiento, con el email de quien reporta en el cuerpo.
07

Create a comment on an issue

issue.createComment

Lo que ves en n8n

Notas y casos de uso

Añade un comentario a una issue existente, así la conversación se queda donde el equipo ya la lee.

Parámetros clave

  • Issue Number: el número de la issue que recibe el comentario, normalmente arrastrado de un nodo anterior con {{ $json.iid }}.
  • Body: el texto del comentario.
  • Project Owner: el usuario, grupo o namespace del proyecto.
Casos de uso
publicar el resultado de un despliegue en la issue que lo disparó, para que el hilo guarde también el desenlace y no solo la petición.
08

Edit an issue

issue.edit

Lo que ves en n8n

Notas y casos de uso

Actualiza una issue existente y cambia únicamente los campos que añades a la colección.

Parámetros clave

  • Issue Number: qué issue se edita.
  • State, en Edit Fields: closed u open, que es como un flujo cierra un ticket por su cuenta.
  • Title, Body, Labels, Assignees y Due Date: todo lo demás que la colección permite reescribir.
Casos de uso
cerrar la issue asociada en cuanto la merge request que la corrige se fusiona en la rama principal.
09

Get an issue

issue.get

Lo que ves en n8n

Notas y casos de uso

Recupera una issue concreta y devuelve sus datos, sin modificar nada en GitLab.

Parámetros clave

  • Issue Number: el número de la issue que se lee.
  • Project Owner: el usuario, grupo o namespace del proyecto.
Casos de uso
enriquecer un aviso antes de enviarlo. El trigger te da un número, esta operación te da el título, el estado, las etiquetas y las personas asignadas, y el mensaje que sale al equipo por fin dice algo en vez de señalar un identificador.
10

Lock an issue

issue.lock

Lo que ves en n8n

Notas y casos de uso

Bloquea la discusión de una issue: ya no se puede añadir ningún comentario al hilo.

Parámetros clave

  • Issue Number: la issue que se bloquea.
  • Lock Reason: a elegir entre off-topic, too heated, resolved o spam, que deja constancia de por qué se congeló el hilo.
Casos de uso
un proyecto público atrae comentarios sobre asuntos zanjados hace tiempo. Un flujo programado repasa las issues cerradas, las bloquea con resolved, y quienes mantienen el proyecto dejan de responder lo mismo.

Release

5 operaciones
11

Create a release

release.create

Lo que ves en n8n

Notas y casos de uso

Publica una release en el proyecto, asociada a una etiqueta, y la devuelve.

Parámetros clave

  • Tag: la etiqueta de la release, único campo obligatorio además del proyecto.
  • Ref, en Additional Fields: si la etiqueta todavía no existe, GitLab crea la release a partir de esta referencia, un SHA de commit, otro nombre de etiqueta o un nombre de rama.
  • Name y Description: el nombre visible de la release y sus notas.
Casos de uso
publicar la versión desde el mismo flujo que ya ha construido el entregable, con notas armadas a partir de las issues cerradas.
12

Delete a release

release.delete

Lo que ves en n8n

Notas y casos de uso

Borra una release del proyecto. La etiqueta de Git, en cambio, es un objeto distinto de la release.

Parámetros clave

  • Project ID: el identificador o la ruta codificada del proyecto, que las operaciones de release usan en lugar de un propietario a secas.
  • Tag Name: la etiqueta de Git a la que la release está asociada.
  • Project Owner: el usuario, grupo o namespace del proyecto.
Casos de uso
deshacer una release que un pipeline publicó desde la rama equivocada, antes de que alguien la descargue.
13

Get a release

release.get

Lo que ves en n8n

Notas y casos de uso

Devuelve una release, identificada por su etiqueta, con los datos tal como los guarda GitLab.

Parámetros clave

  • Tag Name: la etiqueta de Git a la que la release está asociada.
  • Project ID: el identificador o la ruta codificada del proyecto.
  • Project Owner: el usuario, grupo o namespace del proyecto.
Casos de uso
comprobar que la release existe antes de que siga un flujo de despliegue, y parar la ejecución con limpieza en lugar de empujar una versión que nunca se publicó.
14

Get many releases

release.getAll

Lo que ves en n8n

Notas y casos de uso

Devuelve las releases de un proyecto en forma de lista, un item por release.

Parámetros clave

  • Return All: marcado, n8n recorre todo el historial; sin marcar, se detiene en Limit.
  • Order By, en Additional Fields: created_at o released_at, dos fechas que dejan de coincidir en cuanto una release se prepara con antelación.
  • Sort: asc o desc para el sentido del orden.
Casos de uso
reconstruir el historial de puestas en producción del trimestre, ordenado por fecha de publicación, y enviarlo al panel que revisa producto.
15

Update a release

release.update

Lo que ves en n8n

Notas y casos de uso

Modifica una release ya publicada sin tocar la etiqueta a la que apunta.

Parámetros clave

  • Tag Name: qué release se actualiza.
  • Description, en Additional Fields: las notas de la release, donde se admite Markdown.
  • Milestones: el título de cada hito que asociar, como una lista de títulos separados por comas.
  • Released At: la fecha en la que la release está o estuvo lista.
  • Name: el nombre de la release.
Casos de uso
completar una release con las notas de migración en cuanto el equipo de operaciones las valida.

Repository

2 operaciones
16

Get a repository

repository.get

Lo que ves en n8n

Notas y casos de uso

Devuelve los datos de un repositorio y no pide nada más allá del propio proyecto.

Parámetros clave

  • Project Owner: el usuario, grupo o namespace del proyecto, por ejemplo n8n-io.
Casos de uso
resolver el repositorio al principio de la ejecución. Un solo nodo te devuelve los identificadores y la rama por defecto, y las operaciones posteriores dejan de adivinar en qué rama se supone que escriben.
17

Get issues of a repository

repository.getIssues

Lo que ves en n8n

Notas y casos de uso

Devuelve las issues de un repositorio, filtradas en el servidor y no en un nodo posterior.

Parámetros clave

  • State, en Filters: opened, closed, o vacío para cualquier estado.
  • Labels, Assignee, Creator y Search: acotar por lista de etiquetas, por nombre de usuario, o contra el título y la descripción.
  • Updated After: solo las issues tocadas a partir de una fecha, que es la base de un resumen diario.
  • Return All y Limit: la lista entera o una lista con tope.
Casos de uso
cada lunes, sacar las issues modificadas en los últimos 7 días y publicar el resumen.

User

1 operación
18

Get a user's repositories

user.getRepositories

Lo que ves en n8n

Notas y casos de uso

Devuelve los repositorios de un usuario, un grupo o un namespace, un item por repositorio.

Parámetros clave

  • Project Owner: el usuario, grupo o namespace cuyos repositorios quieres, por ejemplo n8n-io.
Casos de uso
alimentar un bucle. Listas los repositorios del namespace del equipo, repites la misma operación de archivo o de issue en cada uno, y la regla se aplica a todo el namespace en vez de al único repositorio que alguien recordó.
Necesitas ayuda

¿Necesitas ayuda para automatizar GitLab con n8n?

El equipo te responde directamente.

Cada mensaje lo lee una persona.

FAQ

GitLab y n8n: las preguntas que vienen después

01¿La integración de GitLab es gratuita en n8n?
Sí. El nodo GitLab y el GitLab Trigger vienen incluidos con n8n, así que no hay nada que instalar ni ningún coste extra por el lado de n8n. Eso vale tanto en n8n Cloud, la oferta alojada por n8n, como en una instancia autoalojada con la Community Edition bajo licencia Sustainable Use. Un flujo se comporta igual en los dos sitios, de modo que puedes prototipar en uno y ejecutar en el otro. Lo que cueste GitLab depende de tu propio plan y queda fuera de n8n. Lo único que suma la automatización es el tiempo de ejecución de los flujos que decidas lanzar.
02¿Qué credenciales o permisos hacen falta para GitLab?
Hay dos métodos y los dos autentican igual el nodo y el trigger. El primero es el token de acceso de la API: se crea en Edit profile, luego Access tokens, y se introduce en n8n junto con la URL de tu GitLab Server, un campo que importa en cuanto la instancia está autoalojada. El segundo es OAuth2, el recomendado: registras una aplicación en GitLab, copias la OAuth Redirect URL que muestra n8n en el campo Redirect URI, y después el Application ID y el Secret pasan a ser Client ID y Client Secret. Sobre permisos, el scope api cubre todas las operaciones del nodo; elige algo más estrecho si sabes exactamente qué ejecutas.
03¿Qué límites tiene una integración GitLab n8n?
El nodo cubre 5 recursos, archivos, issues, releases, repositorios y usuarios, con 18 operaciones en total. Todo lo que quede fuera de esa lista, y la API de GitLab es mucho más amplia, pasa por el nodo HTTP Request, que llama al endpoint directamente reutilizando la misma credencial de GitLab. Dos detalles despistan a menudo. Los listados están paginados: sin Return All, el nodo se detiene en Limit y pierdes filas sin enterarte. Y las operaciones de release identifican el proyecto con Project ID, el identificador o la ruta codificada, mientras que archivos e issues usan Project Owner, así que un flujo suele arrastrar los dos valores.
04¿El GitLab Trigger reacciona en tiempo real?
Sí, funciona por webhook. Cuando activas el flujo, n8n registra una URL de webhook en GitLab, y GitLab llama a esa URL en cada evento al que te hayas suscrito, de manera que el contenido llega en segundos. No hay bucle de polling ni intervalo que configurar, lo que también significa que un flujo desactivado no recibe nada. Eliges qué llega con el parámetro Events, entre 12 tipos de eventos que cubren pushes, etiquetas, merge requests, pipelines, jobs, despliegues, releases, issues, comentarios y páginas de wiki. Una entrada comodín se suscribe a todos a la vez, cómodo mientras exploras el contenido de cada evento.
05¿n8n o Make para automatizar GitLab?
Depende de dónde estén tus restricciones. Make está alojado únicamente por Make y se factura por operación: resulta previsible con poco volumen y sube con cada paso que añades a un escenario. n8n funciona en su propio Cloud o en tus servidores, así que un flujo que manipula código fuente puede quedarse dentro de tu red, y el coste sigue a la instancia en lugar de al número de operaciones. Make ofrece un editor visual que muchos equipos leen más rápido de un vistazo. En GitLab concretamente, el criterio que decide suele ser el control de los datos: código, tickets y notas de versión no son lo primero que un equipo quiere hacer pasar por un tercero.