GitHub Actions

GitHub Actions предоставляет гибкий конвейер непрерывной интеграции, подходящий для автоматизации запуска браузерных тестов на Puppeteer. Основная сложность заключается в правильной настройке окружения, способного выполнять Chromium без сбоев и системных зависимостей. При корректной конфигурации конвейер воспроизводит локальный сценарий тестирования и формирует артефакты для анализа.

Минимальная конфигурация workflow

Для базового сценария достаточно задать workflow с триггером push или pull_request, определить операционную систему и версии Node.js, а затем установить зависимости и выполнить тестовую команду.

Пример минимального workflow: 

name: puppeteer-tests

on:
  push:
  pull_request:

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npm test

Такой конвейер позволит запускать Puppeteer в headless-режиме при условии, что проект использует встроенный Chromium.

Системные зависимости Chromium

В некоторых проектах требуется установка дополнительных системных библиотек, поскольку Chromium зависит от графических и сетевых компонентов. На Ubuntu-раннерах можно использовать пакетный менеджер apt: 

- name: Install dependencies
  run: |
    sudo apt-get update
    sudo apt-get install -y \
      libnss3 \
      libgtk-3-0 \
      libasound2 \
      libxss1 \
      libgbm1

Указанные библиотеки обеспечивают корректную работу рендеринга, аудио-подсистемы и управления окнами.

Headless-режим и флаги запуска

Для консольного окружения GitHub Actions используется headless-режим. Puppeteer позволяет задавать дополнительные флаги для повышения стабильности: 

const browser = await puppeteer.launch({
  headless: true,
  args: [
    &
    '--disable-setuid-sandbox',
    '--disable-dev-shm-usage'
  ]
});

Флаги no-sandbox и disable-dev-shm-usage уменьшают вероятность падений, связанных с ограничениями контейнерной среды.

Кэширование зависимостей

Оптимизация времени выполнения достигается использованием кэша node_modules или npm-кэша. Поддерживается встроенное кэширование через actions/setup-node: 

- uses: actions/setup-node@v4
  with:
    node-version: 20
    cache: 'npm'

Кэширование сокращает длительность установки зависимостей и делает конвейер предсказуемее при частых коммитах.

Многоверсионное тестирование Node.js

Для проверки совместимости можно запускать Puppeteer на нескольких версиях Node.js с помощью matrix-стратегии: 

strategy:
  matrix:
    node: [18, 20, 22]

Матрица помогает выявлять несовместимости между окружениями и зависимостями, которые локально могут оставаться незамеченными.

Снимки и артефакты

В тестах Puppeteer нередко используется снятие скриншотов и PDF-отчетов. Для сохранения таких данных применяется механизм артефактов: 

- name: Upload screenshots
  uses: actions/upload-artifact@v4
  with:
    name: screenshots
    path: ./screenshots

Артефакты позволяют изучать результаты после завершения workflow, что особенно полезно при анализе падений.

Использование Puppeteer с локальным Chromium

Некоторые проекты отключают автоматическую загрузку Chromium и используют системный браузер. В таком случае необходимо установить браузер вручную и указать путь: 

- run: sudo apt-get update && sudo apt-get install -y chromium-browser

В коде Puppeteer задается путь: 

puppeteer.launch({
  executablePath: '/usr/bin/chromium-browser',
  headless: true
});

Этот подход уменьшает размер зависимостей и ускоряет установку, но требует контроля совместимости версий.

Параллельное выполнение тестов

Большие тестовые пакеты можно разделить на несколько job’ов или шардов. Разделение уменьшает время ожидания и снижает вероятность таймаутов. Для Puppeteer характерно значительное потребление ресурсов, поэтому стоит контролировать количество одновременно открытых браузеров и вкладок.

Отладка падений

Для анализа нестабильных тестов используется сбор логов, снятие скриншотов при ошибках и сохранение трассировки. Несколько библиотек расширяют Puppeteer возможностью генерировать детальные отчеты, которые можно прикреплять как артефакты. В случае воспроизводимых сбоев целесообразно запускать workflow в режиме workflow_dispatch, чтобы повторять тестирование вручную.

Самодостаточные контейнеры

При необходимости максимального контроля над окружением применяется Docker. GitHub Actions поддерживает собственные контейнеры или образы, публикуемые в реестрах. В контейнере можно предустановить Chromium, системные зависимости и Node.js. Этот вариант упрощает воспроизводимость и снижает вероятность различий между локальной средой и CI.

Контроль ресурсов и таймаутов

Puppeteer-тесты могут зависать при сетевых задержках или ошибках рендеринга. Настройка таймаутов и ожиданий минимизирует риск блокирования job’ов. Кроме стандартных параметров Puppeteer, стоит настроить таймауты Jest, Mocha или другого тест-раннера.

Интеграция с PR-работой

GitHub Actions позволяет прикреплять статусы к Pull Request. После выполнения тестов формируется отчет, показывающий, прошла ли проверка. При использовании arifacts обеспечивается дополнительная прозрачность для ревьюеров, которые могут изучать визуальные изменения и сравнивать ожидаемые и фактические результаты.

Ключевые моменты

  • Headless-режим необходим для CI-окружения.
  • Требуются системные зависимости Chromium.
  • Кэширование ускоряет выполнение.
  • Матрица версий помогает обнаруживать несовместимости.
  • Артефакты повышают наглядность анализа результатов.
  • Контейнеризация обеспечивает воспроизводимость.

Такой набор приемов формирует надежный конвейер для автоматизированного тестирования Puppeteer в GitHub Actions и делает процесс предсказуемым даже для крупных проектов.

Оглавление