Настройка правил ревью кода
Managed Service for GitLab позволяет гибко настраивать обязательные правила ревью кода, прежде чем код может быть добавлен в целевую ветку проекта. Подробнее о механизме работы правил см. в разделе Правила ревью кода.
Перед началом работы создайте служебный аккаунт с правами администратора и добавьте его в GitLab-проект. Назначьте аккаунту рольMaintainer
или Owner
: пользователям с другими ролями не хватит прав для настройки правил ревью. Далее войдите в инстанс GitLab и настройте правила ревью через служебный аккаунт.
Чтобы пользоваться правилами ревью кода:
- Создайте токен GitLab.
- Включите правила ревью.
- Настройте правила ревью.
- Настройте Code Ownership (доступно в Стандартной и Продвинутой конфигурации).
При необходимости включите режим отладки и ознакомьтесь с правилами обработки исключительных ситуаций.
Создайте токен GitLab
Токен GitLab нужен, чтобы включить правила ревью и обращаться к репозиторию, так как токен используется для аутентификации в API GitLab.
Чтобы создать токен:
-
Откройте инстанс GitLab.
-
Нажмите на иконку профиля и выберите пункт Edit profile.
-
В меню слева перейдите в раздел Access Tokens.
-
Нажмите кнопку Add new token.
-
В открывшемся окне, в поле Token name, укажите имя, по которому будет удобно искать токен в GitLab-проекте.
-
В поле Expiration date укажите дату, когда срок жизни токена истечет.
Значение по умолчанию — срок истекает через месяц от даты создания токена, максимальное значение — через год. Срок жизни токена истекает в полночь UTC в указанный день.
-
В блоке Select scopes выберите опцию api.
-
Нажмите кнопку Create personal access token.
Появится новый токен.
-
Скопируйте и сохраните его. Далее его нельзя будет скопировать в GitLab.
Включите правила ревью
- Включите настройку GitLab, запрещающую интеграцию с целевой веткой до разрешения всех дискуссий в мерж-реквесте:
- Откройте проект в GitLab.
- В меню слева выберите Settings → Merge requests.
- В блоке Merge checks включите опцию All threads must be resolved.
- Нажмите кнопку Save changes.
- Добавьте системный хук:
- Откройте инстанс GitLab.
- В меню слева выберите Search or go to → Admin Area.
- В меню слева выберите System Hooks.
- Нажмите кнопку Add new webhook.
- Укажите параметры хука:
- URL —
http://localhost:24080/default
. - В блоке Trigger выключите все опции, кроме Merge request events, Push events и Repository update events.
- URL —
- Нажмите кнопку Add system hook.
- Включите настройку GitLab, разрешающую отправлять сообщения в локальную сеть:
- Откройте инстанс GitLab.
- В меню слева выберите Search or go to → Admin Area.
- В меню слева выберите Settings → Network.
- В блоке Outbound requests включите опцию Allow requests to the local network from system hooks.
- В списке IP-адресов и доменных имен укажите адрес
http://localhost:24080
. - Нажмите кнопку Save changes.
- Включите правила ревью кода в инстансе Managed Service for GitLab:
-
В консоли управления
Yandex Cloud выберите каталог, в котором находится инстанс GitLab. -
Выберите сервис Managed Service for GitLab.
-
Выберите инстанс и нажмите кнопку
Редактировать в верхней части страницы. -
В поле Правила ревью кода выберите нужную конфигурацию правил ревью кода.
Примечание
Выбранная конфигурация влияет на стоимость использования вычислительных ресурсов инстанса.
-
В поле Gitlab токен укажите созданный ранее токен.
-
Нажмите кнопку Сохранить.
-
Настройте правила ревью
Правила ревью кода для репозитория хранятся в файле APPROVALRULES
в корневой директории. Конфигурация считывается из ветки по умолчанию
Файл состоит из двух блоков:
ApprovalRules
— описывает сами правила.BranchGroups
— описывает применимость правил к определенным веткам.
Структура файла APPROVALRULES
:
ApprovalRules:
- <имя_правила>:
approvers:
- <имя_пользователя>
...
groups:
- <имя_группы>
...
count: <необходимое_количество_подтверждений>
BranchGroups:
- <имя_группы_веток>:
branches:
- <имя_ветки>
...
rules:
- <имя_правила>
...
Где:
approvers
— имя пользователя GitLab, который может одобрить мерж-реквест.groups
— имя группы GitLab, пользователи которой могут одобрить мерж-реквест.branches
— имя ветки, изменения в которую требуют ревью.rules
— имя правила, которое применяется к указанным веткам.
Вместо имени пользователя и в именах веток допускается использование подстановочного символа *
.
Например, чтобы применить «принцип четырех глаз» для основной ветки репозитория, добавьте в файл
APPROVALRULES
:ApprovalRules: - FourEyesRule: approvers: - "*" count: 1 BranchGroups: - Master: branches: - master rules: - FourEyesRule
Настройте Code Ownership
Функциональность доступна в Стандартной и Продвинутой конфигурации.
Настройки Code Ownership для репозитория хранятся в файле CODEOWNERS
в корневой директории. Конфигурация считывается из ветки по умолчанию
Структура файла поддерживает синтаксис GitLab
Примечание
Если одновременно несколько записей в CODEOWNERS
включают в себя один и тот же файл или директорию, применяются правила из последней записи.
Чтобы использовать настройки Code Ownership при обработке мерж-реквестов в определенные ветки, добавьте следующую запись в файл APPROVALRULES
:
BranchGroups:
- <имя_группы_веток>:
branches:
- <имя_ветки>
...
rules:
- CODE_OWNERS
Отладка
Добавьте в описание мерж-реквеста ключевое слово detailed_AR
, чтобы в дискуссии выводилась расширенная информация по каждому правилу:
- Имена пользователей, одобривших мерж-реквест.
- Оставшееся количество необходимых подтверждений.
- Имена оставшихся пользователей, которые могут одобрить мерж-реквест.
Обработка исключительных ситуаций
Некорректная конфигурация правил ревью
Проблемы, связанные с файлом APPROVALRULES
, обрабатываются следующим образом:
- Если файл отсутствует в репозитории, к мерж-реквестам этого репозитория не применяются никакие правила ревью кода.
- Если файл есть, но настроен некорректно:
- Пользователи с ролью
Maintainer
получают уведомление об ошибке на электронную почту. - Все мерж-реквесты этого репозитория блокируются.
- Пользователи с ролью
Обход правил
Если нужно принять изменения в мерж-реквесте, а нужные члены команды отсутствуют и не могут его одобрить, пользователь с ролью Maintainer
или выше может сделать это в обход заданных правил:
- Добавьте в мерж-реквест комментарий с ключевым словом
force_merge
. - Измените описание мерж-реквеста, чтобы Managed Service for GitLab получил информацию о том, что мерж-реквест изменен.
После этого техническая дискуссия будет закрыта и интеграция мерж-реквеста будет разблокирована. При интеграции пользователи с ролью Maintainer
и выше получат уведомление на электронную почту о нарушении установленного процесса ревью кода.