Перейти к основному содержимому

Настройка CI

Введение

Тесты Playwright можно запускать у любого CI-провайдера. В этом руководстве показан один из способов запуска тестов на GitHub с помощью GitHub Actions. Если вы хотите узнать больше или понять, как настроить других CI-провайдеров, посмотрите нашу подробную документацию по Continuous Integration.

Вы узнаете

Настройка GitHub Actions

При установке Playwright с помощью расширения VS Code или через npm init playwright@latest вам предлагается добавить workflow для GitHub Actions. В результате создаётся файл playwright.yml в папке .github/workflows, содержащий всё необходимое, чтобы ваши тесты запускались при каждом push и pull request в ветку main/master. Вот как выглядит этот файл:

.github/workflows/playwright.yml
name: Playwright Tests
on:
push:
branches: [ main, master ]
pull_request:
branches: [ main, master ]
jobs:
test:
timeout-minutes: 60
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v5
- uses: actions/setup-node@v5
with:
node-version: lts/*
- name: Install dependencies
run: npm ci
- name: Install Playwright Browsers
run: npx playwright install --with-deps
- name: Run Playwright tests
run: npx playwright test
- uses: actions/upload-artifact@v4
if: ${{ !cancelled() }}
with:
name: playwright-report
path: playwright-report/
retention-days: 30

Workflow выполняет следующие шаги:

  1. Клонирует ваш репозиторий
  2. Устанавливает Node.js
  3. Устанавливает зависимости NPM
  4. Устанавливает браузеры Playwright
  5. Запускает тесты Playwright
  6. Загружает HTML-отчёт в интерфейс GitHub

Чтобы узнать больше об этом, см. "Понимание GitHub Actions".

Создание репозитория и пуш в GitHub

После того как вы настроите workflow GitHub Actions, останется только создать репозиторий на GitHub или отправить код в уже существующий репозиторий. Следуйте инструкциям GitHub и не забудьте инициализировать git-репозиторий командой git init, чтобы затем вы могли добавлять, коммитить и пушить свой код.

Создание репозитория и пуш в GitHub

Открытие рабочих процессов

Перейдите на вкладку Actions, чтобы увидеть workflow. Там вы увидите, прошли ли ваши тесты или упали.

открытие рабочего процесса

Просмотр логов тестов

Клик по запуску workflow покажет все действия, которые выполнил GitHub, а клик по Run Playwright tests — сообщения об ошибках, что ожидалось и что было получено, а также лог вызовов.

Просмотр логов тестов

HTML-отчет

HTML Report показывает полный отчёт по вашим тестам. Вы можете фильтровать отчёт по браузерам, пройденным тестам, упавшим тестам, пропущенным тестам и нестабильным (flaky) тестам.

Загрузка HTML-отчета

В разделе Artifacts нажмите на playwright-report, чтобы скачать отчёт в виде zip-архива.

Загрузка HTML-отчета

Просмотр HTML-отчета

Локально открыть отчёт «как есть» не получится: чтобы всё работало корректно, нужен веб‑сервер. Сначала распакуйте zip, желательно в папку, где уже установлен Playwright. Затем в командной строке перейдите в каталог с отчётом и выполните npx playwright show-report, указав имя распакованной папки. Команда поднимет сервер с отчётом и позволит посмотреть его в браузере.

npx playwright show-report name-of-my-extracted-playwright-report

просмотр HTML-отчета

Чтобы узнать больше об отчётах, посмотрите наше подробное руководство по HTML Reporter.

Просмотр трассировки

После того как вы запустили отчет с помощью npx playwright show-report, нажмите на иконку трассировки рядом с именем файла теста, как показано на изображении выше. Вы сможете просмотреть трассировку ваших тестов и исследовать каждое действие, чтобы попытаться выяснить, почему тесты не проходят.

просмотр трассировки Playwright

Публикация отчета в интернете

Загрузка HTML-отчета в виде zip-файла не очень удобна. Однако мы можем использовать возможности статического хостинга веб-сайтов Azure Storage, чтобы легко и эффективно публиковать HTML-отчеты в интернете, требуя минимальной настройки.

  1. Создайте учетную запись Azure Storage.

  2. Включите хостинг статических веб-сайтов для учетной записи хранения.

  3. Создайте Сервисный Принципал в Azure и предоставьте ему доступ к Azure Blob Storage. После успешного выполнения команда отобразит учетные данные, которые будут использованы на следующем шаге.

    az ad sp create-for-rbac --name "github-actions" --role "Storage Blob Data Contributor" --scopes /subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP_NAME>/providers/Microsoft.Storage/storageAccounts/<STORAGE_ACCOUNT_NAME>
  4. Используйте учетные данные из предыдущего шага для настройки зашифрованных секретов в вашем репозитории GitHub. Перейдите в настройки вашего репозитория, в раздел секреты GitHub Actions, и добавьте следующие секреты:

    • AZCOPY_SPA_APPLICATION_ID
    • AZCOPY_SPA_CLIENT_SECRET
    • AZCOPY_TENANT_ID

    Подробное руководство о том, как авторизовать сервисный принципал (service principal) с помощью client secret, см. в этой документации Microsoft.

  5. Добавьте шаг, который загружает HTML-отчёт в Azure Storage.

    .github/workflows/playwright.yml
    ...
    - name: Upload HTML report to Azure
    shell: bash
    run: |
    REPORT_DIR='run-${{ github.run_id }}-${{ github.run_attempt }}'
    azcopy cp --recursive "./playwright-report/*" "https://<STORAGE_ACCOUNT_NAME>.blob.core.windows.net/\$web/$REPORT_DIR"
    echo "::notice title=HTML report url::https://<STORAGE_ACCOUNT_NAME>.z1.web.core.windows.net/$REPORT_DIR/index.html"
    env:
    AZCOPY_AUTO_LOGIN_TYPE: SPN
    AZCOPY_SPA_APPLICATION_ID: '${{ secrets.AZCOPY_SPA_APPLICATION_ID }}'
    AZCOPY_SPA_CLIENT_SECRET: '${{ secrets.AZCOPY_SPA_CLIENT_SECRET }}'
    AZCOPY_TENANT_ID: '${{ secrets.AZCOPY_TENANT_ID }}'

Содержимое контейнера хранения $web может быть доступно из браузера с использованием публичного URL веб-сайта.

примечание

Этот шаг не будет работать для pull request’ов, созданных из форка, потому что такой workflow не имеет доступа к секретам.

Правильная работа с секретами

Артефакты вроде файлов трассировки, HTML-отчётов или даже логов консоли содержат информацию о выполнении ваших тестов. Они могут содержать чувствительные данные: учётные данные тестового пользователя, токены доступа к staging-бэкенду, исходники тестов, а иногда даже исходный код вашего приложения. Обращайтесь с этими файлами так же осторожно, как и с этими чувствительными данными. Если вы загружаете отчёты и трассы как часть CI-workflow, убедитесь, что вы загружаете их только в доверенные хранилища артефактов или шифруете файлы перед загрузкой. То же касается обмена артефактами с коллегами: используйте доверенный файлообменник или шифруйте файлы перед отправкой.

Что дальше