Agente de revisión de código con n8n: del webhook de PR al comentario publicado
Crea paso a paso un agente de revisión de código con n8n: conecta un webhook de pull request de GitHub o GitLab a un AI Agent que revisa diffs y publica comentarios.
Comprobado con las fuentes citadas el .
Qué vas a construir: un agente de revisión de código con n8n, de la PR al comentario
Este es un ejercicio editorial, no una implementación que hayamos ejecutado o verificado de principio a fin: es una tarea autocontenida que puedes intentar por tu cuenta. El objetivo es diseñar un agente de revisión de código con n8n que vigile una pull request o merge request, lea el diff, lo compare con las convenciones escritas de tu equipo y publique un comentario estructurado de vuelta en la PR o MR, sin que nadie tenga que copiar texto entre herramientas.
El nodo AI Agent de n8n no puede razonar sobre un diff por sí solo. La documentación oficial de n8n indica que el nodo requiere al menos un subnodo de herramienta conectado antes de poder ejecutarse, así que cualquier diseño de agente de revisión de código con n8n necesita darle al agente algo que pueda invocar, ya sea una herramienta para obtener el diff, un documento de convenciones, o ambos.
Sources: AI Agent | Nodes | n8n Docs
Requisitos previos y entradas que necesitarás
Antes de conectar nada, ten preparadas cuatro cosas: una instancia de n8n, en la nube o autoalojada, una cuenta de GitHub o GitLab con un repositorio contra el que puedas probar con seguridad, credenciales de API con permisos limitados a ese repositorio, y una cuenta de proveedor de IA cuyo modelo pienses invocar desde el nodo AI Agent.
En cuanto a las credenciales, la propia documentación de n8n recomienda un token de acceso personal con el ámbito repo para la mayoría de las operaciones del nodo de GitHub, mientras que una credencial de GitLab se documenta como necesitada del ámbito api, más amplio, para desbloquear toda la funcionalidad del nodo. Como este flujo de trabajo solo necesita leer diffs y publicar comentarios, esa indicación de GitLab apunta a más acceso del que la tarea requiere estrictamente.
Sources: GitHub credentials | Nodes | n8n Docs, n8n-docs/docs/integrations/builtin/credentials/gitlab.md at main · n8n-io/n8n-docs · GitHub
Construyendo el flujo de trabajo: cinco pasos del webhook al comentario
La forma general de un flujo de revisión de código con n8n es breve: un disparador, una obtención del diff, una consulta de convenciones, una llamada al agente y una publicación del comentario. El diagrama de abajo muestra ese orden; los párrafos siguientes cubren las decisiones que importan en cada etapa.
La propia documentación del nodo de GitHub enumera operaciones de pull request que incluyen obtener el diff o el patch directamente, junto con eventos del GitHub Trigger para la actividad normal de pull request, el envío de revisiones y los comentarios de revisión. El disparador de GitLab expone de forma similar un evento de merge request, pero las operaciones documentadas del nodo de la app de GitLab cubren archivos, issues, releases, repositorios y usuarios, sin ninguna acción de merge request listada para obtener un diff o publicar un comentario. Una implementación documentada de la comunidad sortea esa carencia llamando a la API de GitLab a través de un nodo HTTP Request, el patrón que usó para su flujo de revisión de código con n8n en GitLab.
| Paso | Nodo de la app de GitHub | Nodo de la app de GitLab |
|---|---|---|
| Obtener el diff | Operación documentada Get Diff / Get Patch | Sin operación de merge request documentada; la única implementación documentada de la comunidad que revisamos usó HTTP Request |
| Publicar comentario | Operación documentada de creación de comentarios | Sin operación de merge request documentada; la única implementación documentada de la comunidad que revisamos usó HTTP Request |
| Evento de disparo | Eventos de pull request, revisión y comentarios de revisión | Evento de merge request junto con issues, pipelines y otra actividad |
Para las convenciones del equipo, una implementación documentada de la comunidad conecta una Google Sheet con los estándares de código del equipo como una herramienta que el AI Agent puede consultar, en lugar de pegar las reglas dentro del texto del prompt. Creemos que ese enfoque basado en herramientas merece la configuración extra: mantiene un único flujo de trabajo reutilizable entre repositorios con distintos estándares, en vez de bifurcar el prompt cada vez que cambia una regla.
Una vez que el agente tiene tanto el diff como las convenciones, la siguiente decisión de diseño es la forma de la salida. Pedirle al modelo una salida estructurada, por ejemplo un array JSON con campos de archivo, línea y comentario, y analizarla con el Structured Output Parser de n8n le da al paso de publicación del comentario datos predecibles con los que trabajar, en la línea de cómo una implementación documentada de la comunidad dio forma a sus comentarios de revisión en GitLab. En una entrada de blog independiente de la comunidad sobre la construcción de una automatización de revisión de código con IA, el desarrollador Harsh Jolapara describe ese mismo tipo de automatización así:
Publicar la respuesta suele ser la llamada de nodo más sencilla: el nodo de GitHub incluye una operación de creación de comentarios, y una implementación documentada de la comunidad la usa para publicar el feedback de la IA una vez que el agente termina; el equivalente en GitLab pasa de nuevo por un nodo HTTP Request en la única implementación documentada de la comunidad que revisamos para GitLab. En cualquier caso, trata el comentario de la IA como una opinión preliminar en la PR, no como una condición para fusionar.
Sources: AI Agent | Nodes | n8n Docs, GitHub Trigger | Nodes | n8n Docs, GitHub | Nodes | n8n Docs, GitLab Trigger | Nodes | n8n Docs, n8n-docs/docs/integrations/builtin/app-nodes/n8n-nodes-base.gitlab.md at main · n8n-io/n8n-docs · GitHub, Automate GitHub Code Reviews with n8n’s AI Agent | by Anirban Mukherjee ✍️ | Medium, Can AI Be Your Code Reviewer? Building an Automated Merge Request Reviewer with n8n and LLM | by Rerngrit Frank | Medium
Restricciones y criterios de finalización
El ámbito del token, los límites de frecuencia y el tamaño del diff son las tres restricciones con más probabilidad de darte problemas. Limita al mínimo el alcance de las credenciales: un PAT de GitHub con el ámbito repo, o un token de GitLab con el alcance más estrecho que tu plataforma permita, por debajo del amplio ámbito api que la documentación de n8n describe como la opción fácil por defecto.
Los límites de frecuencia difieren según la plataforma. La API de GitHub espera que los clientes esperen hasta el momento indicado en su cabecera de reinicio del límite de frecuencia antes de reintentar, y GitLab limita específicamente la creación de comentarios en issues y merge requests a un límite documentado en GitLab.com, separado de sus límites generales de API; las instancias de GitLab autogestionadas o dedicadas fijan sus propios límites, algo que la documentación menciona sin dar una cifra. Nosotros diseñaríamos desde el principio con reintentos progresivos y un tope máximo de reintentos, en lugar de añadirlo después de que un flujo de trabajo supere un límite en producción.
- Ámbito de token mínimo para la plataforma que uses
- Reintentos progresivos cuando se active la cabecera de reinicio del límite de frecuencia de GitHub
- Tener en cuenta que GitLab limita la creación de comentarios por separado de las llamadas generales a la API
- Un límite de tamaño del diff para que las pull requests demasiado grandes no saturen el contexto del agente
Considera el ejercicio completo cuando una pull o merge request genuinamente nueva dispare el flujo de trabajo del agente de revisión de código con n8n, tanto el diff como las convenciones lleguen al AI Agent, el agente devuelva una salida estructurada que el flujo de trabajo pueda analizar sin correcciones manuales, y aparezca en la PR o MR un comentario que refleje el contenido real del diff.
Sources: GitHub credentials | Nodes | n8n Docs, n8n-docs/docs/integrations/builtin/credentials/gitlab.md at main · n8n-io/n8n-docs · GitHub, Rate limits for the REST API - GitHub Docs, GitLab.com rate limits | GitLab Docs
Reflexión, resolución de problemas y un boceto de solución sugerida
Un agente de revisión de código con n8n que funcione bien debería resultar aburrido en el buen sentido: se activa en silencio con las nuevas pull requests y deja un único comentario útil, nada más. Como ninguno de los tutoriales en los que se basa este ejercicio documenta el manejo de errores para una llamada fallida a la IA o una publicación de comentario fallida, y ninguna fuente aquí confirma el esquema exacto de comentario que espera el nodo de cada plataforma, trataríamos todo el flujo como un borrador que hay que probar en un repositorio de bajo tráfico antes de confiar en él para algo importante. Nuestra recomendación pragmática: evita la publicación totalmente automatizada al principio y dirige la salida del agente a un canal privado durante una semana antes de dejarlo comentar en pull requests reales.
Entre los puntos de fallo típicos que vale la pena revisar durante las pruebas están un diff demasiado grande que el modelo trunca o gestiona mal, una salida estructurada que casi, pero no del todo, coincide con el esquema de tu parser, y una llamada de publicación de comentario que falla en silencio después de que la llamada a la IA ya haya tenido éxito.
Si quieres practicar el patrón subyacente, conectar un nodo AI Agent a una única herramienta con memoria conversacional, antes de añadir encima un disparador de webhook y dos API externas, el reto Tu primer agente de IA construye exactamente esa combinación en tu propio entorno de n8n.
Sources: AI Agent | Nodes | n8n Docs, Automate GitHub Code Reviews with n8n’s AI Agent | by Anirban Mukherjee ✍️ | Medium, Can AI Be Your Code Reviewer? Building an Automated Merge Request Reviewer with n8n and LLM | by Rerngrit Frank | Medium
