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

Что проверяют

Понимаете ли вы разницу между «договорились писать описания» и механизмом, который не даёт влить MR без них. Заодно проверяют, умеете ли вы вводить процессные изменения, не вызывая сопротивления команды. Следом часто спрашивают, что должно быть в описании фронтенд-изменения.

Как отвечать

Разложите на три шага: договорённость, шаблон, автоматическая проверка.

• шаблон: в GitLab это файлы в .gitlab/merge_request_templates/, шаблон по умолчанию задаётся в настройках проекта или файлом Default.md в этом каталоге. В GitHub это .github/pull_request_template.md, несколько шаблонов кладут в .github/PULL_REQUEST_TEMPLATE/;
• содержимое: что и зачем меняется, ссылка на задачу, как проверить, риски. Для фронтенда обязательно скриншоты или видео «до» и «после», ссылка на review-стенд или превью-деплой, Storybook, если менялись компоненты, отметка о проверке в нужных браузерах и на мобильной ширине;
• проверка в CI: шаблон сам по себе ничего не требует, его можно стереть. Требование появляется, когда пайплайн падает на пустом описании. В GitLab job с правилом на merge_request_event проверяет $CI_MERGE_REQUEST_DESCRIPTION, а в настройках включается «Pipelines must succeed». В GitHub это action на событие pull_request плюс обязательный статус в branch protection или rulesets. Удобная обёртка для таких правил: Danger JS, он работает и с GitHub, и с GitLab;
• внедрение: сначала шаблон и мягкое предупреждение, пара недель на привыкание, потом жёсткая блокировка.

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

Где спотыкаются

Считают, что шаблон уже делает описание обязательным. Без проверки в CI его стирают или оставляют пустым.

Делают шаблон на два экрана с десятком обязательных пунктов. Люди начинают писать «n/a» во всех полях, и формальное описание ничем не лучше пустого.

Вешают проверку только на открытие MR. Автор дописал описание, а статус остался красным: в GitHub нужно подписаться на тип события edited, в GitLab пайплайн придётся перезапустить вручную.