GitHub ruleset: как требовать обязательный workflow перед merge

Как устроено правило required workflows

GitHub позволяет на уровне организации или enterprise выбрать конкретный workflow из репозитория-источника и сделать его обязательным перед merge в целевых репозиториях. Workflow должен быть доступен по совместимой видимости: например, private workflow не может бесконтрольно запускаться в репозитории, которому он недоступен. Документация также ограничивает поддерживаемые триггеры правила событиями `pull_request`, `pull_request_target` и `merge_group`; фильтры этих событий ruleset может игнорировать.

Совет: Начинайте с Evaluate/пилотного набора, если такой режим доступен в вашем плане.

Как настроить централизованный workflow

1. Откройте Organization Settings → Repository → Rulesets и создайте либо отредактируйте branch ruleset.
2. Выберите целевые репозитории и ветки, для которых должна действовать проверка.
3. В Rules включите `Require workflows to pass before merging` и нажмите Add workflow.
4. Выберите репозиторий-источник, ref и YAML-файл workflow, который должен проходить перед merge.
5. Переведите ruleset в Active только после теста на пилотном репозитории и проверки событий pull_request/merge_group.

Что происходит с уже открытыми PR

Если создать required-workflow rule, когда pull request уже открыт, GitHub предупреждает: workflow не запускается автоматически только из-за появления правила. Для запуска может понадобиться новый commit, Update branch либо закрытие и повторное открытие PR. Это важно при rollout на большую организацию, иначе старые PR внезапно будут выглядеть заблокированными без очевидного run. Также сначала проверьте, что workflow не зависит от path/branch filters, которые ruleset трактует иначе.

Предупреждение: Не рассчитывайте на произвольные workflow events: ruleset workflows поддерживают конкретный набор PR-событий.

Перед массовым включением

• проверить план GitHub и доступность org/enterprise ruleset workflows;
• убедиться в совместимой visibility workflow-репозитория;
• добавить поддерживаемый event trigger;
• протестировать поведение существующего PR.

Почему новый ruleset может не запустить старый PR

Required workflow действует как правило для событий GitHub Actions, а уже открытый pull request не всегда автоматически генерирует нужное событие после создания правила. GitHub рекомендует обновить PR: добавить коммит, синхронизировать ветку или переоткрыть его, чтобы workflow запустился. Это стоит учесть при включении ruleset на активном репозитории, иначе существующие PR могут неожиданно оставаться без нового required check.

Пример общего security-check

Организация хранит `security-gate.yml` в центральном private репозитории и хочет запускать его перед merge в десятках private repos. Вместо копирования YAML правило ruleset указывает на один workflow. После пилота команда включает Active для выбранной группы. Открытые до этого PR принудительно обновляют ветку, чтобы required workflow получил событие и создал check.

Важно: Учитывайте план, visibility и права доступа — наличие обычных Actions ещё не гарантирует доступность required workflow ruleset.

Что учитывать

Required workflow действует как правило для событий GitHub Actions, а уже открытый pull request не всегда автоматически генерирует нужное событие после создания правила. GitHub рекомендует обновить PR: добавить коммит, синхронизировать ветку или переоткрыть его, чтобы workflow запустился. Это стоит учесть при включении ruleset на активном репозитории, иначе существующие PR могут неожиданно оставаться без нового required check.

Источники и проверка

Фактическая часть сверена по первичным источникам (в т.ч. Available rules for rulesets). Пример и формулировки — редакция N1RO на 2026-09-23.

• Available rules for rulesets