На каком этапе обычно запускаются тесты в CI/CD: до или после merge pull request?

В типичном пайплайне CI/CD тесты запускаются на нескольких этапах, но ключевой момент — до merge pull request. Когда разработчик открывает PR, система CI автоматически собирает проект и прогоняет набор тестов на ветке с изменениями. Это называется quality gate: если тесты падают, PR нельзя смерджить.

Почему именно до merge

• Ошибки ловятся в изолированной ветке, не ломая main.
• Ревьюер видит зелёный статус CI и понимает, что код как минимум не сломал существующие тесты.
• Снижается риск «сломанного окна»: если main часто красный, команда теряет доверие к пайплайну.

Что происходит после merge

После слияния обычно запускается ещё один пайплайн: сборка артефакта, интеграционные и e2e-тесты, деплой на staging или production. Эти тесты дороже и медленнее, поэтому их часто выносят за пределы PR-проверок.

Пример пайплайна

on: pull_request
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm test

on:
  push:
    branches: [main]
jobs:
  deploy:
    steps:
      - run: npm run build
      - run: npm run e2e
      - run: ./deploy.sh

Итог: тесты до merge — обязательный фильтр для защиты основной ветки, а тесты после merge — этап доставки и дополнительной валидации. Применяйте такой подход, чтобы не пропускать регрессии в main и держать пайплайн быстрым и предсказуемым.