Правила ревью кода в Managed Service for GitLab
Managed Service for GitLab позволяет гибко настраивать обязательные правила ревью кода, прежде чем код может быть добавлен в целевую ветку проекта. Функциональность является альтернативой встроенному в GitLab Enterprise Edition инструменту Approval Rules и доступна вне зависимости от версии GitLab.
Если в инстансе GitLab включены правила ревью кода, Managed Service for GitLab анализирует подтверждения от ревьюеров на соответствие заданным правилам. Если подтверждений недостаточно, в мерж-реквесте создается техническая дискуссия, блокирующая его интеграцию в целевую ветку. При изменении мерж-реквеста в дискуссии создается или обновляется комментарий с текущим статусом соответствия правилам. Когда все необходимые подтверждения получены, дискуссия закрывается.
Если закрыть техническую дискуссию вручную, она будет создана заново. В случае интеграции мерж-реквеста в обход заданных правил пользователи с ролью Maintainer и выше получат уведомление на электронную почту о нарушении установленного процесса ревью кода.
Подробнее о работе с правилами ревью см. в разделе Настройка правил ревью кода.
Примеры использования
Токен GitLab
Токен GitLab нужен, чтобы настроить правила ревью кода. Токен запрашивается для авторизации при взаимодействии с репозиторием — так происходит обращение к API GitLab.
Токен GitLab обладает сроком жизни, который задается во время создания токена. Срок жизни истекает в полночь UTC в указанный день. Максимальный срок жизни — год с момента создания токена.
Накануне истечения срока GitLab отправляет уведомление о том, что приближается окончание срока жизни токена. Уведомление приходит на электронную почту аккаунта, от лица которого был создан токен.
Выпустите новый токен и добавьте его в настройки инстанса GitLab до того, как истечет срок жизни прежнего токена. Иначе сервис Managed Service for GitLab будет работать некорректно.
Примеры использования
Доступные конфигурации
Примечание
Выбранная конфигурация влияет на стоимость использования вычислительных ресурсов инстанса.
Вы можете выбрать нужную конфигурацию, исходя из задач команды:
- Базовая — включает возможность создания одного правила на каждый проект без дополнительных условий. Подходит для небольших команд (до 10 человек).
- Стандартная — позволяет настроить несколько правил на каждый проект и назначить владельцев кода (Code Owners) на определенные файлы или директории (не более 10 записей). Подходит для команд среднего размера (от 10 до 30 человек).
- Продвинутая — включает в себя возможности стандартной конфигурации без ограничения на количество записей Code Ownership и позволяет настраивать разные правила ревью для разных веток проекта. Подходит для больших команд (больше 30 человек).
Подробное сравнение возможностей конфигураций см. в таблице:
| Функциональность | Описание | Базовая конфигурация |
Стандартная конфигурация |
Продвинутая конфигурация |
|---|---|---|---|---|
| Одно правило ревью на проект | Возможность выбрать группу пользователей, один из которых должен провести ревью перед объединением веток. | |||
| Защищенные ветки | Возможность выбрать ветки, для которых действуют правила ревью. | |||
| Code Ownership | Возможность закрепить определенные файлы и директории (в т. ч. по маске) за определенными пользователями. Такие пользователи становятся владельцами кода (code owners) и могут принимать участие в ревью, если коммиты в мерж-реквесте затрагивают их файлы. | |||
| Несколько правил ревью | Возможность задавать больше одного правила ревью на проект. | |||
| Правила для разных веток | Возможность задавать разные правила ревью для разных веток, например release и master. |