n8n Code Review Agent: від вебхука PR до опублікованого коментаря
Крокова побудова агента рев'ю коду на n8n: з'єднайте вебхук pull request із GitHub чи GitLab з AI-агентом, який перевіряє diff і публікує коментарі.
Перевірено за наведеними джерелами .
Що ви створите: агент рев'ю коду на n8n від PR до коментаря
Це редакційна вправа, а не збірка, яку ми запускали чи перевіряли від початку до кінця: самодостатнє завдання, яке ви можете спробувати виконати самостійно. Мета — спроєктувати агента рев'ю коду на n8n, який стежить за pull request або merge request, читає diff, перевіряє його на відповідність письмовим конвенціям вашої команди та публікує структурований коментар назад у PR чи MR, без ручного копіювання тексту між інструментами.
Вузол AI Agent в n8n не може самостійно аналізувати diff. Офіційна документація n8n зазначає, що вузол потребує щонайменше одного під'єднаного інструмента (tool sub-node), перш ніж він зможе запуститися, тож будь-який дизайн агента рев'ю коду на n8n має давати агенту щось, що він може викликати — чи то інструмент для отримання diff, чи документ із конвенціями, чи обидва разом.
Sources: AI Agent | Nodes | n8n Docs
Передумови та вхідні дані, які вам знадобляться
Перш ніж щось з'єднувати, підготуйте чотири речі: інстанс n8n (хмарний або self-hosted), обліковий запис GitHub чи GitLab із репозиторієм, на якому можна безпечно тестувати, облікові дані API, обмежені цим репозиторієм, та обліковий запис провайдера ШІ, модель якого ви плануєте викликати з вузла AI Agent.
Щодо облікових даних, власна документація n8n рекомендує персональний токен доступу зі скоупом repo для більшості операцій вузла GitHub, тоді як для облікових даних GitLab документація вказує на потребу в ширшому скоупі api, щоб розблокувати повну функціональність вузла. Оскільки цьому workflow потрібно лише читати diff і публікувати коментарі, ця рекомендація для GitLab передбачає більше доступу, ніж строго необхідно для завдання.
Sources: GitHub credentials | Nodes | n8n Docs, n8n-docs/docs/integrations/builtin/credentials/gitlab.md at main · n8n-io/n8n-docs · GitHub
Побудова workflow: п'ять кроків від вебхука до коментаря
Загальна форма workflow рев'ю коду на n8n коротка: тригер, отримання diff, пошук конвенцій, виклик агента та публікація коментаря. Діаграма нижче показує цей порядок; абзаци після неї розкривають важливі рішення на кожному етапі.
Власна документація вузла GitHub перелічує операції для pull request, які включають пряме отримання diff чи patch, поряд із подіями GitHub Trigger для звичайної активності pull request, подання рев'ю та коментарів рев'ю. Тригер GitLab аналогічно надає подію merge request, але задокументовані операції вузла застосунку GitLab охоплюють файли, issues, релізи, репозиторії та користувачів, без жодної перелічненої дії merge request для отримання diff чи публікації коментаря. Одна задокументована спільнотна збірка обходить цю прогалину, звертаючись до API GitLab через вузол HTTP Request — саме такий підхід вона використала для свого workflow рев'ю коду на n8n для GitLab.
| Крок | Вузол застосунку GitHub | Вузол застосунку GitLab |
|---|---|---|
| Отримати diff | Задокументована операція Get Diff / Get Patch | Немає задокументованої операції merge request; єдина задокументована спільнотна збірка, яку ми розглянули, використала HTTP Request |
| Опублікувати коментар | Задокументована операція створення коментаря | Немає задокументованої операції merge request; єдина задокументована спільнотна збірка, яку ми розглянули, використала HTTP Request |
| Подія тригера | Події pull request, review та review-comment | Подія merge request поряд з issues, pipelines та іншою активністю |
Для конвенцій команди одна задокументована спільнотна збірка під'єднує Google Sheet зі стандартами кодування команди як інструмент, до якого AI Agent може звертатися, замість того щоб вставляти правила безпосередньо в текст промпту. Ми вважаємо, що такий підхід на основі інструмента вартий додаткового налаштування: він дозволяє повторно використовувати один workflow для репозиторіїв із різними стандартами, замість форкання промпту щоразу, коли змінюється правило.
Коли агент має і diff, і конвенції, наступне рішення дизайну стосується форми виведення. Якщо попросити модель повернути структурований результат — наприклад, JSON-масив із полями file, line і comment — і розпарсити його за допомогою Structured Output Parser в n8n, крок публікації коментаря отримує передбачувані дані для мапування, що перегукується з тим, як одна задокументована спільнотна збірка формувала свої коментарі рев'ю для GitLab. В окремому блозі спільноти про створення автоматизації рев'ю коду на основі ШІ розробник Harsh Jolapara описує подібну автоматизацію так:
Публікація коментаря назад зазвичай є найпростішим викликом вузла: вузол GitHub включає операцію створення коментаря, і одна задокументована спільнотна збірка використовує її для публікації відгуку ШІ одразу після завершення роботи агента; аналог для GitLab знову проходить через вузол HTTP Request у тій єдиній задокументованій спільнотній збірці для GitLab, яку ми розглянули. У будь-якому разі ставтеся до коментаря ШІ як до чернеткової думки в PR, а не як до умови для злиття.
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
Обмеження та критерії завершення
Скоуп токена, ліміти швидкості запитів та розмір diff — три обмеження, які найімовірніше дадуться взнаки. Обмежуйте облікові дані мінімально: PAT GitHub зі скоупом repo, або токен GitLab із найвужчим скоупом, який дозволяє ваша платформа, нижче широкого скоупу api, який документація n8n описує як простий варіант за замовчуванням.
Ліміти швидкості запитів відрізняються залежно від платформи. API GitHub очікує, що клієнти чекатимуть до часу, вказаного в заголовку скидання ліміту швидкості, перш ніж повторювати спробу, а GitLab спеціально обмежує створення коментарів у issues та merge requests задокументованим лімітом на GitLab.com, окремо від загальних лімітів API; self-managed або виділені інстанси GitLab встановлюють власні ліміти, які документація згадує, не наводячи конкретної цифри. Ми б закладали логіку backoff і максимальну кількість повторних спроб із самого початку, а не додавали б їх уже після того, як workflow перевищить ліміт у продакшні.
- Мінімальний скоуп токена для платформи, яку ви використовуєте
- Backoff, коли спрацьовує заголовок скидання ліміту швидкості GitHub
- Розуміння того, що GitLab обмежує створення коментарів окремо від загальних викликів API
- Верхня межа розміру diff, щоб надто великі pull requests не перевантажували контекст агента
Вважайте вправу завершеною, коли справді новий pull чи merge request запускає workflow агента рев'ю коду на n8n, і diff, і конвенції досягають AI Agent, агент повертає структурований результат, який workflow може розпарсити без ручних виправлень, і коментар з'являється в PR чи MR, відображаючи реальний вміст 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
Рефлексія, усунення несправностей та ескіз пропонованого рішення
Робочий агент рев'ю коду на n8n має відчуватися нудним у найкращому сенсі: він тихо спрацьовує на нових pull requests і залишає один корисний коментар, не більше. Оскільки жоден з туторіалів, на яких базується ця вправа, не документує обробку помилок для невдалого виклику ШІ чи невдалої публікації коментаря, і жодне джерело тут не підтверджує точну схему коментаря, якої очікує вузол кожної платформи, ми б розглядали весь потік як чернетку, яку варто протестувати на репозиторії з низьким трафіком, перш ніж довіряти йому щось важливе. Наше прагматичне рішення: спершу пропустити повністю автоматизовану публікацію і спрямовувати вивід агента в приватний канал протягом тижня, перш ніж дозволити йому коментувати реальні pull requests.
Типові точки збоїв, які варто перевіряти під час тестування, включають надто великий diff, який модель обрізає чи обробляє неправильно, структурований результат, який майже, але не точно відповідає схемі вашого парсера, та виклик публікації коментаря, який мовчки завершується невдачею вже після успішного виклику ШІ.
Якщо хочете попрактикувати базовий патерн — з'єднання вузла AI Agent з одним інструментом із розмовною пам'яттю, перш ніж додавати вебхук-тригер і два зовнішні API поверх нього, — завдання «Твій перший ШІ-агент» будує саме цю комбінацію у вашому власному середовищі 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
