Звіти, артефакти й метрики CI

Звіти й артефакти: що зберігати і як ділитися

Які звіти. HTML-звіт Playwright (playwright-report/) — для людей: кроки, скріншоти, trace. JUnit XML — для машин: CI і сторонні сервіси показують тести у своєму UI, малюють історію та анотують PR. Зазвичай вмикають обидва: reporter: [['html', { open: 'never' }], ['junit', { outputFile: 'results/junit.xml' }]], а в CI додають github (анотації в логах) чи dot (короткий вивід).

Що вантажити. Трасування, відео та скріншоти — найкращі докази падіння, але важкі. Записуйте їх лише для невдалих тестів чи ретраїв (trace: 'on-first-retry', video: 'retain-on-failure', screenshot: 'only-on-failure'). Для артефактів задавайте retention-days (7–14 днів вистачає) і не вантажте нічого, що не потрібне при успіху.

Шардовані прогони. Кожна шарда формує blob-звіт; окрема job (needs: [e2e]) завантажує всі blob-артефакти (download-artifact@v4 з pattern і merge-multiple: true), виконує npx playwright merge-reports --reporter html ./all-blob-reports і вантажить один HTML-звіт. Job злиття теж має if: ${{ !cancelled() }}, інакше після червоної шарди вона не запуститься.

Як ділитися. Zip-артефакт треба скачати й розпакувати, а HTML-звіт зі статикою неможливо відкрити як окремий файл без сервера. Зручніше публікувати звіт на GitHub Pages чи статичному хостингу і додавати посилання в коментар PR. Для короткого підсумку на сторінці запуску — писати Markdown у файл $GITHUB_STEP_SUMMARY.

Сповіщення. Надсилайте в канал (Slack/Teams) лише важливе: падіння nightly і main, а не кожного PR; у повідомленні — назва набору, кількість падінь, посилання на запуск і звіт.

Метрики CI і розбір падінь (triage)

Пайплайн — продукт, який теж треба міряти. Мінімальний набір:

Тривалість пайплайна: p50 і p90/p95, а не лише середнє. Середнє ховає довгий хвіст, який і дратує команду. Окремо — час очікування раннера в черзі;
Flaky rate — частка тестів (або запусків), що пройшли лише з ретраю, від усіх за період. Дивляться тренд по тижнях і топ найнестабільніших тестів;
Pass rate основної гілки і частка червоних PR через не-код (інфраструктура, flaky);
MTTR червоного main — як швидко повертають зелений статус;
Вартість: хвилини раннерів на PR, розмір артефактів.

Triage падінь (наприклад, nightly: 30 червоних тестів). Не відкривайте їх по одному:

Згрупуйте за повідомленням помилки та стеком — зазвичай 30 падінь це 2–3 причини;
З'ясуйте, коли почалося: який останній зелений запуск, що змінилося між ними (коміти, деплой, версія залежності, дані);
Класифікуйте: дефект продукту, дефект тесту (локатор, гонка, дані), інфраструктура (таймаут, раннер, зовнішній сервіс);
Дефект продукту — тікет розробникам з trace; дефект тесту — виправлення або карантин із власником; інфраструктура — ретрай/запуск вдруге і тікет платформі;
Закрийте петлю: додайте перевірку, що не дасть повторитися.

Важливо розрізняти «червоний через баг» (тест зробив свою роботу) і «червоний через шум». Інакше команда вчиться ігнорувати червоний колір.