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

Настройка 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, убедитесь, что вы загружаете их только в доверенные хранилища артефактов или шифруете файлы перед загрузкой. То же касается обмена артефактами с коллегами: используйте доверенный файлообменник или шифруйте файлы перед отправкой.

Что дальше​