Компьютеры · Инструкция
Как блокировать merge по результатам GitHub Code Scanning через ruleset
Code scanning merge protection связывает результаты анализа кода с возможностью merge. GitHub может учитывать не только имя CI-check, но и факт настройки инструмента, состояние анализа и уровень найденных alerts.
Короткий ответ
Как включить Require code scanning results в branch ruleset, выбрать CodeQL или другой tool и задать пороги, реально блокирующие merge.
Что проверить до включения обязательного Code Scanning
Require code scanning results имеет смысл включать только после того, как выбранный scanner стабильно анализирует все pull requests, на которые распространяется ruleset. Сначала проверьте CodeQL или другой tool без enforcement, разберите типичные alerts и только затем задавайте порог, при котором merge запрещён. Иначе любой пропущенный запуск анализа может остановить нормальную разработку. Команде также нужна понятная процедура для false positive и аварийного bypass: исключение должно быть контролируемым, а не способом регулярно обходить security gate.
Совет: До enforcement убедитесь, что выбранный scanner запускается на каждом PR, который должен проходить через правило.
Что сделать по шагам
- Убедитесь, что code scanning стабильно запускается на PR.
- Откройте Settings → Rules → Rulesets.
- Создайте branch ruleset и включите Require code scanning results.
- Добавьте tool и пороги.
- Протестируйте PR с успешным анализом и alert выше порога.
Предупреждение: Не делайте required инструмент, который не запускается для всех целевых PR.
Что важно учесть в текущей реализации
Require code scanning results в branch ruleset связывает merge с результатами конкретного code scanning tool. При создании правила GitHub предлагает выбрать инструмент, например CodeQL, и пороги для alerts. До enforcement убедитесь, что анализ стабильно запускается на всех целевых PR; иначе технический сбой workflow превратится в постоянную блокировку релизов. Создайте два тестовых PR: один с чистым завершённым анализом и второй с результатом выше выбранного порога. Команда должна видеть понятную причину, почему merge недоступен. Отдельно опишите порядок для false positive и аварийного bypass — не как способ игнорировать security alert, а как контролируемое исключение с последующим разбором.
Важно: Заранее определите процедуру false positive и аварийного bypass.
Проверка результата и крайние случаи
В branch ruleset добавьте Require code scanning results и выберите конкретный tool, например CodeQL, а затем уровни результатов, которые должны блокировать merge. Проверьте два PR: обычный без блокирующих alerts и тестовый с результатом выше порога. Если первый застрял в состоянии ожидания, сначала исправьте запуск scanner, а не ослабляйте security rule. Для false positive используйте документированную процедуру dismiss/triage с объяснением. Аварийный bypass должен быть ограничен небольшим числом доверенных акторов и оставлять понятный аудит причины.
Контрольный список
- Scanner стабильно запускается на целевых PR.
- Ruleset требует результаты выбранного tool.
- Alert выше порога блокирует merge.
- Для false positive и bypass есть контролируемая процедура.
Финальная проверка
После включения ruleset периодически проверяйте, что выбранный scanner всё ещё запускается при изменениях workflow; required gate полезен только пока источник результата стабилен.
Ожидаемый результат
Обычный PR без блокирующего alert должен пройти после завершения scanner, а результат выше заданного порога — удерживать merge.
Последняя проверка перед завершением
Если проект использует несколько scanner, перечислите в ruleset только те результаты, которые действительно обязаны присутствовать на каждом целевом PR, иначе merge будет зависеть от случайного job.
Что учитывать
Require code scanning results в branch ruleset связывает merge с результатами конкретного code scanning tool. При создании правила GitHub предлагает выбрать инструмент, например CodeQL, и пороги для alerts. До enforcement убедитесь, что анализ стабильно запускается на всех целевых PR; иначе технический сбой workflow превратится в постоянную блокировку релизов. Создайте два тестовых PR: один с чистым завершённым анализом и второй с результатом выше выбранного порога. Команда должна видеть…
Источники и проверка
Инструкция составлена редакцией N1RO на 2026-09-22. Перед действием сверьте актуальные условия на официальном сайте сервиса или производителя.