GitLab 19.1: AI-воркфлоу запускаются автоматически по событиям без участия человека

GitLab выпустил версию 19.1, которая переводит AI-воркфлоу из режима «кто-то нажимает кнопку» в режим «работает само» — и одновременно даёт enterprise-командам инструменты контроля за тем, что именно работает.

Четыре триггера для

Duo Flows До 19.1 каждый Duo Flow требовал ручного действия в UI: упомянуть, назначить или добавить ревьюера. Команды, запускающие производственные воркфлоу в масштабе, сталкивались с конкретными ограничениями: ни автоматических сводок по конфликтам, ни проверок compliance на готовых к ревью MR, ни создания инцидентов при падении pipeline — всё это было недоступно без человека в цепочке.

Теперь GitLab 19.1 добавляет четыре событийных триггера: Конфликт в merge request — поток запускается в момент обнаружения конфликта, когда автоматическое резюме и предложения по разрешению наиболее полезны — до того, как разработчик успел открыть MR. Черновик переходит в «готов к ревью» — триггер срабатывает, когда разработчик снимает статус draft, автоматически запуская проверку соответствия требованиям.

MR одобрен — автоматически запускаются постпроверки: готовность к деплою, compliance-логирование, уведомления о передаче. Создан новый рабочий элемент — немедленная сортировка, автоматическое присвоение меток и маршрутизация без внешних webhook-костылей. Два первых триггера активированы по умолчанию: команды получают ценность сразу после обновления до 19.

1. Фильтрация по состояниям pipeline тоже стала точнее: триггер настраивается только на падение, только на успех или только на отмену — вместо реакции на каждое изменение состояния.

Управление агентами в окружении

Для regulated-организаций несогласованный агент — не мелочь, а блокер. Один кастомный flow, появившийся в namespace во время хакатона без проверки безопасности, способен поставить под угрозу весь enterprise-триал. В 19.1 появились два новых административных параметра: Disable custom agents and flows — запрещает пользователям создавать или включать кастомные агенты и потоки, ограничивая их базовым контентом платформы. Restrict the AI catalog to your group hierarchy — блокирует активацию элементов AI Catalog из других namespace, включая community- и third-party-контент. Вместе эти настройки переводят AI-агентов под тот же административный контроль, что уже действует для других чувствительных возможностей платформы. Широкое использование AI становится возможным без риска неконтролируемого распространения агентов в продакшене.

Валидация до сохранения

Событийные потоки, запускающиеся автоматически, ужесточают цену ошибки в конфигурации. Неверно настроенный поток создаёт шум и инциденты по всей организации — GitLab 19.1 переносит проверку в точку сохранения. При сохранении или обновлении потока платформа проверяет конфигурацию против Duo Workflow Service. Если что-то не так — отсутствующий инпут, неизвестный параметр инструмента — структурированные ошибки появляются прямо в UI. Проблема обнаруживается в момент сохранения, а не в три ночи при падении pipeline.

«Каждый поток в AI Catalog правильно сконфигурирован до того, как кто-то начнёт на него полагаться в продакшене», — из официального релиза GitLab 19.1.

Отдельно в публичную бету вышел список разрешённых AI-моделей. Администраторы ограничивают набор провайдеров — например, по требованиям data residency или внутренним политикам безопасности — и задают дефолтную модель для всей организации, сохраняя пользователям гибкость выбора внутри разрешённого списка.

Что это значит

GitLab системно закрывает главный барьер enterprise-внедрения AI: невозможность ответить службе безопасности на вопрос «что именно работает в нашей среде и кто это поставил». Автоматические триггеры, административный контроль и валидация конфигурации превращают AI-воркфлоу из инструментов в инфраструктуру — предсказуемую, управляемую и готовую к продакшену.