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

Нужно запускать обязательную проверку для каждого запроса на слияние и запрещать слияние до её успешного завершения. В показанной конфигурации проверяется только событие push в main, поэтому ошибка обнаруживается уже после изменения общей ветки.

Исторический контекст

Такой контроль появился как часть практики непрерывной интеграции. Раньше команды часто объединяли изменения редко, из-за чего дефекты накапливались, а поиск виновного изменения становился дорогим.

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

Постановка проблемы

Текущая конфигурация реагирует только на публикацию в main. Изменение может попасть в основную ветку, а затем сломать тесты, сборку или совместимость с другими компонентами.

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

Подробное решение

Следует добавить три элемента:

событие запуска на создание или обновление запроса на слияние;
обязательный статус проверки, без которого слияние запрещено;
повторный запуск проверки после изменения запроса, чтобы результат относился к актуальному состоянию кода.

Механизм должен быть логически таким:

on:
  pull_request:
    types: [opened, synchronize, reopened]

jobs:
  quality:
    steps:
      - run: install
      - run: unit-tests
      - run: integration-tests

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

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

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

Ситуация из практики

Команда обнаружила, что разработчики видят результат интеграционных тестов через 20 минут после слияния. За это время в main успевали попасть ещё несколько изменений, и локализация причины занимала значительно больше времени.

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

Выбрали обязательный быстрый набор до слияния: сборка, модульные тесты, проверки API-контрактов и критичные статические анализаторы. Полный регресс оставили отдельным этапом после слияния и перед выпуском. Дополнительно включили аннулирование устаревших результатов после нового коммита.

В результате дефекты стали обнаруживаться до изменения main, а дорогие проверки не блокировали каждую небольшую правку. При этом команда отдельно контролировала, какие проверки действительно являются обязательными для защиты основной ветки.

Что кандидаты часто упускают

Достаточно ли запускать проверку при открытии запроса на слияние?

Нет. Запуск только при открытии проверяет первоначальное состояние. После добавления нового коммита код изменился, поэтому проверку нужно запускать также при обновлении запроса. Иначе успешный старый результат может ошибочно разрешить слияние нового состояния.

Нужно ли выполнять абсолютно все тесты до слияния?

Нет. Критерий выбора — не полнота любой ценой, а достаточное снижение риска при приемлемом времени обратной связи. Быстрые проверки, защищающие сборку и критичные контракты, обычно обязательны, а длительные сценарии можно запускать отдельным этапом, если они не требуются для безопасного слияния.

Что произойдёт, если проверка запущена до слияния, но слияние допускается вручную?

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