Какие проверки (checks) для Pull Request были настроены на вашем последнем проекте?

«Какие проверки (checks) для Pull Request были настроены на вашем последнем проекте?» — вопрос из категории Git, который задают на 24% собеседований AQA / Automation. Ниже — развёрнутый ответ с разбором ключевых моментов.

Ответ

В проекте использовался GitHub, и для основной ветки (main) были настроены строгие правила (branch protection rules), которые требовали прохождения всех обязательных проверок перед мержем PR.

Основные проверки включали:

  • Статический анализ кода (Linting): Запуск ESLint для JavaScript/TypeScript кода. PR не мог быть смержен, если линтер находил ошибки.
  • Запуск юнит-тестов: Пакет jest запускал все юнит-тесты. Падение любого теста блокировало мерж.
  • Проверка покрытия кода (Code Coverage): Инструмент istanbul/nyc вычислял покрытие для измененных файлов. Мы требовали минимум 80% покрытия для новых строк кода.
  • Интеграционные/E2E тесты: Наш CI-пайплайн в GitHub Actions запускал набор критических E2E-тестов на Cypress в headless-режиме.
  • Сборка проекта: Успешная сборка проекта (npm run build) была обязательным условием.
  • Ревью кода: Требовалось минимум одно одобрение (approve) от другого разработчика и одно одобрение от QA-инженера. Я, как QA, проверял не только функциональность, но и наличие/адекватность тестов для изменений.

Конфигурация в .github/workflows/pr-checks.yml выглядела так:

name: PR Checks
on: [pull_request]
jobs:
  verify:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Install dependencies
        run: npm ci
      - name: Run linter
        run: npm run lint
      - name: Run unit tests with coverage
        run: npm run test:coverage
      - name: Build project
        run: npm run build
      - name: Run E2E tests
        run: npm run test:e2e:ci