Связаться с намиПодключиться

Настройка правил ревью кода

Статья создана
Обновлена 6 марта 2025 г.

Managed Service for GitLab позволяет гибко настраивать обязательные правила ревью кода, прежде чем код может быть добавлен в целевую ветку проекта. Подробнее о механизме работы правил см. в разделе Правила ревью кода.

Перед началом работы создайте служебный аккаунт с правами администратора и добавьте его в GitLab-проект. Назначьте аккаунту роль Maintainer или Owner: пользователям с другими ролями не хватит прав для настройки правил ревью. Далее войдите в инстанс GitLab и настройте правила ревью через служебный аккаунт.

Чтобы пользоваться правилами ревью кода:

  1. Создайте токен GitLab.
  2. Включите правила ревью.
  3. Настройте правила ревью.
  4. Настройте Code Ownership (доступно в Стандартной и Продвинутой конфигурации).

При необходимости включите режим отладки и ознакомьтесь с правилами обработки исключительных ситуаций.

Создайте токен GitLab

Токен GitLab нужен, чтобы включить правила ревью и обращаться к репозиторию, так как токен используется для аутентификации в API GitLab.

Чтобы создать токен:

  1. Откройте инстанс GitLab.

  2. Нажмите на иконку профиля и выберите пункт Edit profile.

  3. В меню слева перейдите в раздел Access Tokens.

  4. Нажмите кнопку Add new token.

  5. В открывшемся окне, в поле Token name, укажите имя, по которому будет удобно искать токен в GitLab-проекте.

  6. В поле Expiration date укажите дату, когда срок жизни токена истечет.

    Значение по умолчанию — срок истекает через месяц от даты создания токена, максимальное значение — через год. Срок жизни токена истекает в полночь UTC в указанный день.

  7. В блоке Select scopes выберите опцию api.

  8. Нажмите кнопку Create personal access token.

    Появится новый токен.

  9. Скопируйте и сохраните его. Далее его нельзя будет скопировать в GitLab.

Включите правила ревью

  1. Включите настройку GitLab, запрещающую интеграцию с целевой веткой до разрешения всех дискуссий в мерж-реквесте:
    1. Откройте проект в GitLab.
    2. В меню слева выберите Settings → Merge requests.
    3. В блоке Merge checks включите опцию All threads must be resolved.
    4. Нажмите кнопку Save changes.
  2. Добавьте системный хук:
    1. Откройте инстанс GitLab.
    2. В меню слева выберите Search or go to → Admin Area.
    3. В меню слева выберите System Hooks.
    4. Нажмите кнопку Add new webhook.
    5. Укажите параметры хука:
      • URL — http://localhost:24080/default.
      • В блоке Trigger выключите все опции кроме Merge request events, Push events и Repository update events.
    6. Нажмите кнопку Add webhook.
  3. Включите настройку GitLab, разрешающую отправлять сообщения в локальную сеть:
    1. Откройте инстанс GitLab.
    2. В меню слева выберите Search or go to → Admin Area.
    3. В меню слева выберите Settings → Network.
    4. В блоке Outbound requests включите опцию Allow requests to the local network from system hooks.
    5. В списке IP-адресов и доменных имен укажите адрес http://localhost:24080.
    6. Нажмите кнопку Save changes.
  4. Включите правила ревью кода в инстансе Managed Service for GitLab:

    1. В консоли управления Yandex Cloud выберите каталог, в котором находится инстанс GitLab.

    2. Выберите сервис Managed Service for GitLab.

    3. Выберите инстанс и нажмите кнопку Редактировать в верхней части страницы.

    4. В поле Правила ревью кода выберите нужную конфигурацию правил ревью кода.

      Примечание

      Выбранная конфигурация влияет на стоимость использования вычислительных ресурсов инстанса.

    5. В поле Gitlab токен укажите созданный ранее токен.

    6. Нажмите кнопку Сохранить.

Настройте правила ревью

Правила ревью кода для репозитория хранятся в файле APPROVALRULES в корневой директории. Конфигурация считывается из ветки по умолчанию (default branch) при запуске инстанса и автоматически подгружается при изменении файла.

Файл состоит из двух блоков:

  • ApprovalRules — описывает сами правила.
  • BranchGroups— описывает применимость правил к определенным веткам.

Структура файла APPROVALRULES:

ApprovalRules:
  - <имя_правила>:
      approvers:
        - <имя_пользователя>
        ...
      groups:
        - <имя_группы>
        ...
      count: <необходимое_количество_подтверждений>
BranchGroups:
  - <имя_группы_веток>:
      branches:
        - <имя_ветки>
        ...
      rules:
        - <имя_правила>
        ...

Где:

  • approvers — список имен пользователей GitLab, которые могут одобрить мерж-реквест. Пользователи должны быть добавлены в проект напрямую или через группу. Автор мерж-реквеста не учитывается при подсчете подтверждений. Пользователь из этого списка, который отправлял коммиты в мерж-реквест и не является автором, также может одобрить его.
  • groups — список имен групп GitLab, участники которых могут одобрить мерж-реквест (за исключением участников группы, для которой указанная группа является подгруппой).
  • count – число от 0 до 100. Если указано 0, то правило считается опциональным.
  • branches — список имен веток, изменения в которых требуют ревью.
  • rules — список правил, которые применяются к указанным веткам.

Вместо имени пользователя и в именах веток допускается использование подстановочного символа *.

Например, чтобы применить «принцип четырех глаз» для основной ветки репозитория, добавьте в файл APPROVALRULES:

ApprovalRules:
  - FourEyesRule:
      approvers:
        - "*"
      count: 1
BranchGroups:
  - Master:
      branches:        
        - master
      rules:
        - FourEyesRule

Настройте Code Ownership

Функциональность доступна в Стандартной и Продвинутой конфигурации.

Настройки Code Ownership для репозитория хранятся в файле CODEOWNERS в корневой директории. Конфигурация считывается из ветки по умолчанию (default branch) при запуске инстанса и автоматически подгружается при изменении файла.

Структура файла поддерживает синтаксис GitLab за исключением использования подгрупп пользователей и адресов электронной почты в качестве идентификаторов пользователей.

Примечание

Если одновременно несколько записей в CODEOWNERS включают в себя один и тот же файл или директорию, применяются правила из последней записи.

Чтобы использовать настройки Code Ownership при обработке мерж-реквестов в определенные ветки, добавьте следующую запись в файл APPROVALRULES:

BranchGroups:
  - <имя_группы_веток>:
      branches:        
        - <имя_ветки>
        ...
      rules:
        - CODE_OWNERS

Отладка

Добавьте в описание мерж-реквеста ключевое слово detailed_AR, чтобы в дискуссии выводилась расширенная информация по каждому правилу:

  • Имена пользователей, одобривших мерж-реквест.
  • Оставшееся количество необходимых подтверждений.
  • Имена оставшихся пользователей, которые могут одобрить мерж-реквест.

Обработка исключительных ситуаций

Некорректная конфигурация правил ревью

Проблемы, связанные с файлом APPROVALRULES, обрабатываются следующим образом:

  • Если файл отсутствует в репозитории, к мерж-реквестам этого репозитория не применяются никакие правила ревью кода.
  • Если файл есть, но настроен некорректно:
    • Пользователи с ролью Maintainer получают уведомление об ошибке на электронную почту.
    • Все мерж-реквесты этого репозитория блокируются.

Обход правил

Если нужно принять изменения в мерж-реквесте, а нужные члены команды отсутствуют и не могут его одобрить, пользователь с ролью Maintainer или выше может сделать это в обход заданных правил:

  1. Добавьте в мерж-реквест комментарий с ключевым словом force_merge.
  2. Измените описание мерж-реквеста, чтобы Managed Service for GitLab получил информацию о том, что мерж-реквест изменен.

После этого техническая дискуссия будет закрыта и интеграция мерж-реквеста будет разблокирована. При интеграции пользователи с ролью Maintainer и выше получат уведомление на электронную почту о нарушении установленного процесса ревью кода.

Предыдущая
Создание и добавление пользователей в проект
Следующая
Мониторинг состояния инстанса