Кросс-репозиторное AI-ревью для GitLab

Коротко

Автор описывает систему, которая запускает ревью из одного merge request, но собирает контекст всей связанной задачи во всех затронутых репозиториях. По его оценке, агентное ревью сократило личное время на проверку на 80% и помогло выявлять межсервисные несоответствия; решение оставляет окончательное решение за людьми.

Контекст

Автор — разработчик с примерно 20-летним опытом, который автоматизирует рутинную часть работы тимлида. Он столкнулся с тем, что отдельный MR может выглядеть корректно, хотя изменение ломает контракт между несколькими сервисами. Решение предназначено только для GitLab; автор предлагает готовый проект code-review для подключения к группе репозиториев.

Главное

• Решение предназначено для GitLab и требует версии 17.11 или новее; заявлена совместимость с gitlab.com и self-managed, включая Free/CE.
• Обычные AI-ревьюеры анализируют один diff; здесь агент получает issue, обсуждение, diff и полные клоны всех найденных репозиториев задачи.
• Соседние проекты находятся по упоминаниям коммитов в системных заметках issue; ветка определяется через GET /repository/commits/:sha/refs, поэтому одинаковые имена веток не обязательны.
• Агент проверяет соответствие задаче, правила и границы репозиториев, совместимость контрактов, побочные эффекты, обычные ошибки и безопасность; читает, среди прочего, CLAUDE.md, AGENTS.md, CONTRIBUTING.md, ARCHITECTURE.md и docs/.
• Для соседних репозиториев создаются follower-MR с меткой merge::follower; их описание использует Part of, а не Closes, чтобы преждевременно не закрыть issue.
• Кворум — один голос AI и два человеческих: при 👍 от AI хватает одного человеческого одобрения; при 👎 или отсутствии голоса AI требуются два. Автор MR и боты не засчитываются как одобряющие.
• Основная маршрутизация по умолчанию — gpt-5.3-codex через codex exec; доступны claude-opus-5, gemini-pro-latest, grok-4.6, DeepSeek и Qwen. Метки MR выбирают модель; Draft: или WIP: запускают более дешёвый быстрый проход.
• Архитектура использует два пайплайна: проверяемый проект вызывает пайплайн проекта-ревьюера, где находятся секреты. Запуск передаёт типизированные inputs, а не произвольные pipeline variables.
• Перед публикацией система проверяет, что SHA MR не изменился; для параллельных прогонов используются id пайплайнов и resource_group. Gate ждёт результат AI, а его лог включает вывод downstream-ревью.
• Репозиторий решения: https://gitlab.com/nick-public/code-review. Для блокировки merge требуется включить Pipelines must succeed; инструкции отдельно описывают настройку Free и Premium/Ultimate.

Как сделано

При запуске из MR система извлекает номер issue из имени ветки, затем читает системные заметки issue, чтобы найти репозитории, где есть связанные коммиты. По SHA коммитов GitLab API определяет соответствующие ветки. Репозитории клонируются в общее рабочее пространство; туда же помещаются описание задачи с обсуждением и diff каждого проекта. Агент на базе CLI — например, codex exec, claude или gemini — изучает требования, правила репозиториев, diff и окружающий код, а затем публикует отчёт в MR и голосует 👍 или 👎. Для затронутых соседних проектов он создаёт follower-MR с меткой merge::follower; повторное ревью и голосование там отключены.

Секреты отделены от непроверенного кода: первый пайплайн передаёт запуск во второй, в проекте-ревьюере, где хранятся токен бота и ключи моделей. Вместо pipeline variables используются типизированные inputs GitLab 17.11+, а входящие переменные запрещены настройкой Minimum role to use pipeline variables → No one allowed. Агент запускается без GitLab-токенов и лишних секретов. Merge блокируется через Pipelines must succeed; job verify-approvals проверяет кворум «2 из 3»: при одобрении AI нужен один человеческий 👍, при отклонении или отсутствии голоса AI — два. Модель можно выбрать меткой MR; второе мнение другой модели доступно отдельно и по умолчанию выключено.

Результаты

Автор сообщает, что ранняя схема «diff → модель» давала около 30% ложных замечаний и экономила примерно 20% его времени. После перехода к агенту, который исследует связанные файлы и репозитории, его время на ревью сократилось на 80%. Система прошла более сотни задач; автор утверждает, что не обнаружил ошибок самого AI-ревью и стал спокойнее деплоить. Полное ревью обычно занимает минуты, а в тяжёлых случаях — 10–20 минут; в инструкции для настройки указано, что отдельный запуск может длиться до 45 минут.

Ограничения

Это практический опыт одного автора, а не контролируемое сравнение: не приведены методика измерения экономии времени, независимая оценка качества, статистика ложных срабатываний агентной версии или сравнение моделей. Утверждение об отсутствии ошибок основано на опыте автора. Решение работает только с GitLab 17.11+ и не поддерживает GitHub или Bitbucket. Запуски расходуют токены и CI compute minutes; второе мнение примерно удваивает стоимость. На gitlab.com Free недоступны project access tokens, поэтому используется групповой read-токен с более широкими последствиями утечки. Агенту разрешены инструменты для анализа кода потенциально недоверенных веток, поэтому безопасность строится на ограничении передаваемых ему секретов и окружения, а не на обещании отсутствия prompt injection.

Что взять себе

• Для кросс-сервисных изменений полезно проверять не только diff одного MR, но и связанный код, контракты и требования во всех затронутых репозиториях.
• Агентное ревью оправдано там, где нужно переходить от diff к определениям, вызовам и соседним модулям; простая отправка diff в модель ограничивает видимость.
• Не отдавайте AI безусловное право блокировать или разрешать merge: предусмотрите человеческий кворум и обход при ошибочном отклонении.
• Размещайте ключи моделей и токены с правами записи отдельно от пайплайна, запускающегося на потенциально недоверенном коде; ограничивайте доступ агента к секретам.
• Учитывайте стоимость и длительность: тяжёлые проверки занимают до десятков минут, а отдельное второе мнение увеличивает расход ресурсов.

Читать оригинал, если…

Откройте оригинал, если собираетесь внедрять решение: там есть пошаговая настройка GitLab, CI-конфигурация, команды для токенов и подробности обработки гонок и прав доступа.