Какие автоматические проверки запускают в CI при создании merge request?

Когда разработчик открывает merge request, CI-система (GitLab CI, GitHub Actions, Jenkins и др.) автоматически запускает набор проверок, чтобы убедиться, что изменения не ломают проект и соответствуют стандартам команды. Это снижает нагрузку на ревьюеров и предотвращает попадание багов в основную ветку.

Типовой набор проверок

• Линтеры и форматтеры — ESLint, Prettier, Ruff, golangci-lint проверяют стиль и потенциальные ошибки.
• Статический анализ и типы — tsc, mypy, SonarQube ищут типовые баги и уязвимости.
• Сборка — компиляция или бандлинг проекта, чтобы убедиться, что код собирается.
• Unit-тесты — быстрые тесты отдельных модулей.
• Интеграционные и e2e-тесты — проверка взаимодействия компонентов.
• Проверка зависимостей — npm audit, Snyk, Dependabot на уязвимости.
• Покрытие кода — сравнение с порогом (например, не ниже 80%).

Пример пайплайна в GitLab CI

stages: [lint, test, build]

lint:
  stage: lint
  script:
    - npm ci
    - npm run lint

test:
  stage: test
  script:
    - npm ci
    - npm run test -- --coverage
  coverage: '/Lines\s*:\s*(\d+\.\d+)%/'  # порог покрытия

build:
  stage: build
  script:
    - npm ci
    - npm run build
  only: [merge_requests]

Обычно пайплайн запускается на событие merge_request и блокирует кнопку Merge, пока все job'ы не пройдут успешно. Это создаёт «quality gate»: код нельзя влить, если он не проходит проверки.

Зачем это нужно

• Раннее обнаружение ошибок — дешевле исправить до мержа.
• Единый стиль и качество кода в команде.
• Защита основной ветки от регрессий.
• Ускорение код-ревью: ревьюер смотрит логику, а не опечатки.

Итог: набор CI-проверок в merge request — это автоматизированный контроль качества, который стоит настраивать в любом проекте с командной разработкой, чтобы ловить проблемы до попадания кода в main.