> Как вводится обязательное описание merge requests

Короткий ответ

Обязательное описание merge requests вводится через настройки GitLab (project settings → Merge requests → Merge request checks → Require description) или через push-правила в GitHub Enterprise. Также можно использовать server hooks, CI-проверки или шаблоны merge request description. На уровне GitLab это делается в админке или через API, чтобы запретить создание MR без текста в поле description.

Подробное объяснение

В GitLab обязательное описание включается в настройках проекта или группы: Settings → General → Merge requests → Require description. Это блокирует создание merge request, если поле description пустое. В GitHub Enterprise аналогичная функция доступна через push rules (require_description). Если используется self-hosted GitLab, можно дополнительно настроить server hooks на уровне репозитория - они проверяют payload при создании MR и возвращают ошибку, если description отсутствует.

Также распространён подход с CI-проверкой: в .gitlab-ci.yml добавляется job, который через API проверяет наличие описания у MR и помечает pipeline как failed при его отсутствии. Это работает и в GitLab CE, и в GitHub Actions. Шаблоны описаний (description templates) не делают поле обязательным, но упрощают заполнение - их часто комбинируют с требованием.

На практике

Для GitLab CE (бесплатная версия) настройка "Require description" доступна только в GitLab EE, поэтому на CE используют CI-проверку. Пример: job check-mr-description вызывается только для merge request pipelines, получает описание через API и завершается с ошибкой, если оно пустое. Для GitHub Enterprise включают push rule в настройках репозитория или организации. В случае самописного решения на server hooks нужно учитывать, что hook срабатывает на pre-receive, а не на создание MR - поэтому чаще используют API-проверку в CI.

Пример кода

Пример CI-проверки для GitLab CE:

YAML
check-mr-description:
  stage: test
  only:
    - merge_requests
  script:
    - |
      MR_DESCRIPTION=$(curl -s --header "PRIVATE-TOKEN: $CI_JOB_TOKEN" "$CI_API_V4_URL/projects/$CI_PROJECT_ID/merge_requests/$CI_MERGE_REQUEST_IID" | jq -r '.description')
      if [ -z "$MR_DESCRIPTION" ] || [ "$MR_DESCRIPTION" = "null" ]; then
        echo "Merge request must have a description."
        exit 1
      fi

Для GitHub Actions:

YAML
name: Check MR description
on:
  pull_request:
    types: [opened, edited, reopened]
jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/github-script@v6
        with:
          script: |
            const desc = context.payload.pull_request.body;
            if (!desc || desc.trim() === '') {
              core.setFailed('Pull request must have a description.');
            }

Как отвечать на собеседовании

Начни с прямого ответа: "В GitLab EE есть встроенная опция Require description, в GitHub Enterprise - push rule". Затем упомяни, что для GitLab CE или GitHub Free используют CI-проверку или server hooks. Покажи понимание trade-off: встроенная настройка проще, но недоступна в бесплатных версиях; CI-проверка гибче, но требует поддержки в коде. Если спросят про шаблоны - скажи, что они не делают поле обязательным, а только подсказывают структуру.

Что проверяет интервьюер

Интервьюер хочет убедиться, что ты знаешь не только UI-настройки, но и альтернативные способы для разных версий GitLab/GitHub. Также проверяется понимание, как CI-пайплайны могут взаимодействовать с API для enforcement-политик. Важно показать, что ты различаешь "требование" и "подсказку" - шаблон не заменяет обязательность.

Типичные ошибки

• Утверждение, что "Require description" есть в GitLab CE - это не так, только в EE.
• Путаница между server hooks и pre-receive hooks: server hooks не срабатывают на создание MR, только на push.
• Предложение использовать только шаблоны описаний как решение - это не enforcement.
• Игнорирование того, что в GitHub Free нет push rules - там нужен Actions или внешний сервис.