E2E-набор приносит пользу только тогда, когда исполняется автоматически на каждое изменение. Гоняемый вручную и по настроению, он не защищает ничего: регрессию заметят уже в проде. Задача CI - сделать проверку неотвратимой, но у E2E в CI есть особое требование сверх обычного пайплайна. Эти тесты падают из-за сложного стечения обстоятельств - состояния данных, тайминга, среды, - и без сохранённых доказательств падение на CI невозможно разобрать.

Базовый пайплайн выстраивается предсказуемо. Job на ubuntu забирает код, ставит Node нужной версии с кэшем npm, выполняет npm ci для детерминированной установки по lockfile. Затем ключевой для Playwright шаг - npx playwright install --with-deps, который завозит браузеры и их системные зависимости. Дальше собирают приложение и запускают npx playwright test; сам раннер поднимает webServer и проходит сценарии в настроенных браузерах.

Критическое отличие E2E-пайплайна - сохранение артефактов падения. Шаг upload-artifact сохраняет папку playwright-report после прогона, причём с условием, что он выполнится даже при упавших тестах. Это принципиально: артефакты нужны именно тогда, когда тесты покраснели, а не когда всё зелено. Без этого условия job завершится на падении теста и отчёт с trace'ами - единственный ключ к разбору - просто не сохранится.

Полезно один раз увидеть базовый workflow целиком, чтобы было от чего отталкиваться. Ниже - GitHub Actions с установкой браузеров, прогоном и сохранением отчёта с ретенцией. К этой форме возвращаются, заводя E2E в новом проекте: она уже содержит и обязательный install --with-deps, и сохранение артефактов при падении, без которых пайплайн либо не стартует, либо не даст разобрать красный прогон.

Условие сохранения артефактов заслуживает отдельного внимания. Записывают отчёт с if, срабатывающим, если job не был отменён, - тогда артефакт сохранится и при провале тестов, и при успехе, но не при ручной отмене. Ретенцию ставят разумной - около двух недель: дольше держать отчёты с trace'ами дорого по хранилищу, а короче - рискнуть потерять доказательства падения, которое разбирают не сразу.

Зрелый пайплайн устроен сложнее одного прогона всего подряд. Быстрый smoke-набор из нескольких критических путей блокирует merge и deploy - он короткий и даёт быструю обратную связь. Полный regression гоняют параллельно, не задерживая разработчика. Отчёт и trace сохраняют всегда при падении. А smoke на проде после деплоя проверяет, что живая система работает, - но только read-only, не изменяя реальные данные.