[Документация Yandex Cloud](../../index.md) > [Yandex Managed Service for GitLab](../index.md) > [Пошаговые инструкции](index.md) > Настройка правил ревью кода

# Настройка правил ревью кода в Yandex Managed Service for GitLab

Managed Service for GitLab позволяет гибко настраивать обязательные правила ревью кода, прежде чем код может быть добавлен в целевую ветку проекта. Подробнее о механизме работы правил в разделе [Правила ревью кода](../concepts/approval-rules.md). Примеры конфигурации для типовых сценариев в разделе [Рекомендации по использованию правил ревью кода в Yandex Managed Service for GitLab](../concepts/approval-rules-scenarios.md).

Перед началом работы [создайте служебный аккаунт](create-user.md#create) с правами администратора и [добавьте его в GitLab-проект](create-user.md#add-to-project). Назначьте аккаунту [роль](https://docs.gitlab.com/ee/user/permissions.html) `Maintainer` или `Owner`: пользователям с другими ролями не хватит прав для настройки правил ревью. Далее войдите в инстанс GitLab и настройте правила ревью через служебный аккаунт.

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

1. [Создайте токен GitLab](#gitlab-token).
1. [Включите правила ревью](#enable).
1. [Настройте правила ревью](#rules).
1. [Настройте Code Ownership](#code-ownership) (доступно в **Стандартной** и **Продвинутой** [конфигурации](../concepts/approval-rules.md#packages)).

При необходимости включите [режим отладки](#debugging) и ознакомьтесь с [правилами обработки исключительных ситуаций](#exceptions).

## Создайте токен GitLab {#gitlab-token}

[Токен GitLab](../concepts/approval-rules.md#gitlab-token) нужен, чтобы [включить правила ревью](#enable) и обращаться к репозиторию, так как токен используется для аутентификации в API GitLab.

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

1. Откройте инстанс GitLab.
1. Нажмите на иконку профиля и выберите пункт **Edit profile**.
1. В меню слева перейдите в раздел **Access Tokens**.
1. Нажмите кнопку **Add new token**.
1. В открывшемся окне, в поле **Token name**, укажите имя, по которому будет удобно искать токен в GitLab-проекте.
1. В поле **Expiration date** укажите дату, когда срок жизни токена истечет.

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

1. В блоке **Select scopes** выберите опцию **api**.
1. Нажмите кнопку **Create personal access token**.

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

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

## Включите правила ревью {#enable}

1. Включите настройку GitLab, запрещающую интеграцию с целевой веткой до разрешения всех дискуссий в мерж-реквесте:
    1. Откройте проект в GitLab.
    1. В меню слева выберите **Settings** → **Merge requests**.
    1. В блоке **Merge checks** включите опцию **All threads must be resolved**.
    1. Нажмите кнопку **Save changes**.
1. Добавьте системный хук:
    1. Откройте инстанс GitLab.
    1. В меню слева выберите **Search or go to** → **Admin Area**.
    1. В меню слева выберите **System Hooks**.
    1. Нажмите кнопку **Add new webhook**.
    1. Укажите параметры хука:
        * **URL** — `http://localhost:24080/default`.
        * В блоке **Trigger** выключите все опции кроме **Merge request events**, **Push events** и **Repository update events**.
    1. Нажмите кнопку **Add webhook**.
1. Включите настройку GitLab, разрешающую отправлять сообщения в локальную сеть:
    1. Откройте инстанс GitLab.
    1. В меню слева выберите **Search or go to** → **Admin Area**.
    1. В меню слева выберите **Settings** → **Network**.
    1. В блоке **Outbound requests** включите опцию **Allow requests to the local network from system hooks**.
    1. В списке IP-адресов и доменных имен укажите адрес `http://localhost:24080`.
    1. Нажмите кнопку **Save changes**.
1. Включите правила ревью кода в инстансе Managed Service for GitLab:
    1. В [консоли управления](https://console.yandex.cloud) Yandex Cloud выберите [каталог](../../resource-manager/concepts/resources-hierarchy.md#folder), в котором находится [инстанс GitLab](../concepts/index.md#instance).
    1. Перейдите в сервис **Managed Service for GitLab**.
    1. Выберите инстанс и нажмите кнопку ![image](../../_assets/console-icons/pencil.svg) **Редактировать** в верхней части страницы.
    1. В поле **Правила ревью кода** выберите нужную [конфигурацию](../concepts/approval-rules.md#packages) правил ревью кода.

        {% note warning %}
        
        За использование правил ревью кода в Managed Service for GitLab взимается плата в зависимости от используемой [конфигурации](../concepts/approval-rules.md#packages). Подробнее читайте на странице [Правила тарификации для Yandex Managed Service for GitLab](../pricing.md).
        
        {% endnote %}

    1. В поле **Gitlab токен** укажите [созданный ранее токен](#gitlab-token).
    1. Нажмите кнопку **Сохранить**.

{% note tip %}

Если при обращении к системному хуку возникают проблемы, используйте IP-адрес `127.0.0.1` вместо `localhost`:

1. В параметрах системного хука (**Admin area** → **System Hooks**) измените значение **URL** на `http://127.0.0.1:24080/default`.
1. В настройках GitLab, разрешающих отправлять сообщения в локальную сеть (**Admin area** → **Settings** → **Network** → **Expand outbound requests**, поле ввода для CIDR), добавьте `http://127.0.0.1:24080` в список IP-адресов и доменных имен.

{% endnote %}

## Настройте правила ревью {#rules}

Правила ревью кода для репозитория хранятся в файле `APPROVALRULES` в корневой директории. Конфигурация считывается из [ветки по умолчанию](https://docs.gitlab.com/ee/user/project/repository/branches/default.html) (default branch) при запуске инстанса и автоматически подгружается при изменении файла.

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

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

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

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

Где:

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

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

> Например, чтобы применить «принцип четырех глаз» для основной ветки репозитория, добавьте в файл `APPROVALRULES`:
>
> ```text
> ApprovalRules:
>   - FourEyesRule:
>       approvers:
>         - "*"
>       count: 1
> BranchGroups:
>   - Master:
>       branches:        
>         - master
>       rules:
>         - FourEyesRule
> ```

## Настройте Code Ownership {#code-ownership}

Функциональность доступна в **Стандартной** и **Продвинутой** [конфигурации](../concepts/approval-rules.md#packages).

Настройки Code Ownership для репозитория хранятся в файле `CODEOWNERS` в корневой директории. Конфигурация считывается из [ветки по умолчанию](https://docs.gitlab.com/ee/user/project/repository/branches/default.html) (default branch) при запуске инстанса и автоматически подгружается при изменении файла.

Структура файла поддерживает [синтаксис GitLab](https://docs.gitlab.com/ee/user/project/codeowners/reference.html) за исключением использования подгрупп пользователей и адресов электронной почты в качестве идентификаторов пользователей.

{% note info %}

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

{% endnote %}

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

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

## Отладка {#debugging}

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

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

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

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

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

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

### Обход правил {#force-merge}

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

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

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