Тесты которые запускаются только на твоём ноутбуке ничего не блокируют. Разработчик может смержить код который сломает твой тест-сьют, и ты не узнаешь об этом пока не запустишь тесты вручную. Здесь разобрано как подключить Playwright-тесты к GitHub Actions, GitLab CI и Jenkins чтобы они запускались автоматически на каждый пул-реквест, с полным ready-to-use воркфлоу для GitHub Actions и различиями в конфигурации между тремя платформами.

Что CI/CD реально означает для QA

CI расшифровывается как Continuous Integration. Идея: каждый раз когда разработчик пушит код, автоматический процесс компилирует код, запускает тесты, сообщает о результатах. Проблемы обнаруживаются в течение минут после внесения, а не через дни ручного тестирования.

CD расшифровывается как Continuous Delivery (или Deployment). После прохождения CI код автоматически деплоится на staging или в продакшн.

Для QA-инженера релевантна часть CI. Твои тесты запускаются в пайплайне. Каждый пул-реквест их триггерит. Если тесты падают, PR нельзя смержить. Это контракт.

Тесты только на ноутбуке ничего не обеспечивают. Тесты в CI обеспечивают планку качества на каждое изменение, автоматически.

GitHub Actions: начни здесь

Из трёх инструментов GitHub Actions проще всего для старта и наиболее широко используется в новых проектах. Бесплатен для публичных репозиториев, имеет щедрый бесплатный тариф для приватных.

Концепция: определяешь воркфлоу в YAML-файле внутри репозитория. GitHub запускает этот воркфлоу при каждом триггерном событии: push, пул-реквест, расписание.

Создай .github/workflows/playwright.yml в корне проекта:

mkdir -p .github/workflows

# .github/workflows/playwright.yml
name: Playwright Tests

on:
  push:
    branches: [main, master]
  pull_request:
    branches: [main, master]

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'npm'

      - name: Install dependencies
        run: npm ci

      - name: Install Playwright browsers
        run: npx playwright install --with-deps

      - name: Run Playwright tests
        run: npx playwright test

      - name: Upload test report
        uses: actions/upload-artifact@v4
        if: always()
        with:
          name: playwright-report
          path: playwright-report/
          retention-days: 14

Закоммить этот файл, запушить на GitHub, открыть вкладку Actions. Воркфлоу запустится. Установит Node, установит браузеры Playwright, запустит тесты, загрузит HTML-отчёт как скачиваемый артефакт.

if: always() на шаге загрузки означает что отчёт загружается даже при падении тестов: именно тогда он нужнее всего.

Разбор файла воркфлоу

on: определяет что триггерит воркфлоу. Конфиг выше запускается при пушах в main и на пул-реквесты нацеленные на main. Добавь workflow_dispatch: если хочешь кнопку ручного запуска в интерфейсе GitHub. runs-on: ubuntu-latest задаёт тип машины. Ubuntu стандартен для Playwright. На нём основан Docker-образ Playwright, и зависимости браузеров работают без дополнительной настройки. npm ci вместо npm install. ci устанавливает строго то что в package-lock.json без его модификации, что важно для воспроизводимости в CI. npx playwright install --with-deps устанавливает браузеры И их системные зависимости. На свежем Ubuntu-раннере браузерам нужны системные библиотеки которые не предустановлены. --with-deps обрабатывает это автоматически.

Переменные окружения в GitHub Actions

Никогда не хардкоди credentials в файле воркфлоу. Храни их как GitHub Secrets и ссылайся как на переменные окружения.

Перейди в репозиторий, Settings, Secrets and variables, Actions, New repository secret. Добавь TEST_USER и TEST_PASS.

Ссылайся на них в воркфлоу:

      - name: Run Playwright tests
        run: npx playwright test
        env:
          TEST_USER: ${{ secrets.TEST_USER }}
          TEST_PASS: ${{ secrets.TEST_PASS }}
          BASE_URL: https://lab.becomeqa.com

В тестах обращайся как process.env.TEST_USER. Секреты маскируются в логах. GitHub заменяет их значения на * если они появляются в выводе.

Ускорение тестов через шардирование

По умолчанию Playwright использует несколько воркеров на одной машине. Для больших сьютов можно разделить на несколько машин через шардирование.

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        shard: [1, 2, 3, 4]

    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'npm'
      - run: npm ci
      - run: npx playwright install --with-deps
      - run: npx playwright test --shard=${{ matrix.shard }}/4

Запускает 4 задания параллельно, каждое обрабатывает 25% тестов. Сьют занимающий 20 минут на одной машине занимает 5 минут разделённый на четыре.

Начни без шардирования. Добавляй когда сьют занимает больше 5 минут. Шардирование добавляет сложность. Не оптимизируй до того как это нужно.

GitLab CI

GitLab CI использует те же концепции что GitHub Actions, но другой синтаксис. Файл конфигурации: .gitlab-ci.yml в корне проекта.

# .gitlab-ci.yml
image: mcr.microsoft.com/playwright:v1.44.0-jammy

stages:
  - test

playwright:
  stage: test
  script:
    - npm ci
    - npx playwright test
  artifacts:
    when: always
    paths:
      - playwright-report/
    expire_in: 1 week
  variables:
    TEST_USER: $TEST_USER
    TEST_PASS: $TEST_PASS

Ключевые отличия от GitHub Actions:

Поле image: указывает Docker-образ для задания. Использование официального образа Playwright (mcr.microsoft.com/playwright) означает что браузеры уже установлены, поэтому npx playwright install не нужен.

artifacts в GitLab эквивалентен upload-artifact в GitHub Actions. when: always обеспечивает загрузку даже при падении.

Переменные задаются в GitLab, Project, Settings, CI/CD, Variables. Ссылайся с $VARIABLE_NAME в конфиге.

Если знаешь GitHub Actions, GitLab CI освоишь за день. Ментальная модель идентична: триггеры, задания, шаги, артефакты. Просто другой YAML.

Jenkins

Jenkins старше, сложнее, и всё ещё доминирует в крупных enterprise-окружениях. Встретишь его в компаниях с legacy-инфраструктурой.

Jenkins использует Jenkinsfile в корне проекта:

pipeline {
  agent {
    docker {
      image 'mcr.microsoft.com/playwright:v1.44.0-jammy'
    }
  }

  environment {
    TEST_USER = credentials('test-user')
    TEST_PASS = credentials('test-pass')
  }

  stages {
    stage('Install') {
      steps {
        sh 'npm ci'
      }
    }

    stage('Test') {
      steps {
        sh 'npx playwright test'
      }
      post {
        always {
          publishHTML(target: [
            reportDir: 'playwright-report',
            reportFiles: 'index.html',
            reportName: 'Playwright Report'
          ])
        }
      }
    }
  }
}

Jenkins требует работающего Jenkins-сервера. Это не облачный сервис. Кто-то должен установить, настроить и поддерживать его. Именно поэтому GitHub Actions в основном вытеснил Jenkins в новых проектах.

Для QA конкретно: если приходишь в компанию использующую Jenkins, не нужно разбираться в администрировании Jenkins. Нужно понимать синтаксис Jenkinsfile достаточно чтобы добавить или изменить тестовые стейджи. Pipeline DSL (синтаксис выше): именно с ним QA-инженеры работают ежедневно.

Какой инструмент учить первым

Решение прямолинейно.

Сначала GitHub Actions. Бесплатен, не требует настройки сервера, имеет крупнейшее сообщество, используется в большинстве новых проектов. Можно запустить тесты в CI в течение часа с нуля. GitLab CI вторым если целишься в компании использующие GitLab (распространено в европейском enterprise, финансовых сервисах, госсекторе). Концепции переносятся напрямую из GitHub Actions. Jenkins третьим. Не потому что умирает, а потому что понимание GitHub Actions сначала упрощает изучение Jenkins, и знание Jenkins наиболее полезно в средах где CI-команда уже управляет сервером. Как QA-инженер не будешь настраивать Jenkins с нуля.

Как выглядит реальный CI-пайплайн

Зрелый Playwright-пайплайн в реальном проекте обычно содержит больше чем просто «запустить тесты»:

# Реалистичный production-пайплайн
jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npx tsc --noEmit        # проверка типов TypeScript
      - run: npx eslint tests/       # линтинг тестовых файлов

  test:
    needs: lint
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 20, cache: 'npm' }
      - run: npm ci
      - run: npx playwright install --with-deps
      - run: npx playwright test --project=chromium  # быстрая обратная связь в одном браузере
        env:
          BASE_URL: ${{ vars.BASE_URL }}
          TEST_USER: ${{ secrets.TEST_USER }}
          TEST_PASS: ${{ secrets.TEST_PASS }}
      - uses: actions/upload-artifact@v4
        if: always()
        with:
          name: playwright-report
          path: playwright-report/

  test-cross-browser:
    needs: test
    if: github.ref == 'refs/heads/main'  # только на main-ветке
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 20, cache: 'npm' }
      - run: npm ci
      - run: npx playwright install --with-deps
      - run: npx playwright test  # все браузеры

Паттерн: сначала быстрая обратная связь (lint + Chromium), затем полное кросс-браузерное тестирование на main-ветке. Пул-реквесты получают быстрые результаты, мержи в main получают тщательное покрытие.

Не запускай кросс-браузерные тесты на каждый PR сразу. Это утраивает время CI, а большинство багов не специфичны для браузера. Запускай кросс-браузерное тестирование только при мерже в main пока сьют не достигнет зрелости.

FAQ

Тесты проходят локально но падают в GitHub Actions. В чём проблема

Проверь три вещи: переменные окружения (секреты не заданы в Actions), базовый URL (захардкоженный localhost которого нет в CI), тайминг (CI-раннеры медленнее, поэтому добавь retries: 1 в playwright.config.ts для CI).

Как посмотреть Playwright-отчёт при падении в CI

В GitHub Actions: перейди к упавшему запуску, Summary, Artifacts, скачай playwright-report. Распакуй zip и открой index.html в браузере.

Можно ли в CI запускать только изменившиеся тесты

Нативно в Playwright нет. Некоторые команды используют фильтрацию по путям: запускают только тесты в tests/auth/ когда изменились файлы в src/auth/. Надёжно настроить сложно. Начни с запуска полного сьюта, оптимизируй позже если он станет слишком медленным.

Как запускать тесты по расписанию (например каждую ночь)

Добавь триггер расписания:

on:
  schedule:
    - cron: '0 2 * * *'   # 2:00 UTC каждую ночь
  push:
    branches: [main]

Ночные запуски полезны для выявления нестабильных падений которые не проявляются при каждом PR-запуске.

→ See also: GitHub Actions для тестов Playwright: полная настройка (2026) | GitLab CI + Playwright: полное руководство по настройке | Jenkins + Playwright: построение CI пайплайна с нуля | Параллельное выполнение в Playwright: workers, шарды и шардирование для ускорения