Відеобібліотека
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Показує найкоротший workflow path від checkout до smoke tests без винесення setup у composite action.
Pull request або manual dispatch створює smoke job на ubuntu-latest і запускає pytest marker smoke.
2. Практика та написання пайплану CI/CD →Створіть workflow з pull_request і workflow_dispatch.
Запустіть lint та smoke в окремих jobs.
Збережіть report завжди, а traces — після failure.
Навмисно зламайте один smoke test і пройдіть шлях від job log до локального trace.
Smoke і regression jobs передають reports/results через artifacts.
upload-artifact v4+ створює immutable artifacts: кілька jobs не можуть дописувати один artifact з однаковим name. Smoke і regression outputs потребують унікальних names і явного merge у publish job.
upload-artifact v4; перевірено за GitHub Docs 2026-07-31.
2. Практика та написання пайплану CI/CD →Мінімальна конфігурація реєструє marker smoke і змушує pytest відхиляти невідомі markers.
Тест із @pytest.mark.smoke збирається без unknown-marker error.
1. Налаштування Playwright та Pytest, простий репортінг →Зареєструйте marker smoke і позначте ним один UI test.
Налаштуйте tracing=retain-on-failure.
Навмисно зламайте locator у test environment.
Відкрийте trace.zip і знайдіть failed action, console та network context.
Є відтворюваний failed test і trace, за яким можна назвати точну причину падіння.
Візьміть artifact із навмисно failed Playwright test.
Розпакуйте лише зовнішній archive і знайдіть внутрішній trace.zip.
За Trace Viewer назвіть першу дію, де actual state відрізняється від expected.
Зробіть одну вузьку зміну й підтвердьте її повним smoke run.
Завантажений trace відкривається через Playwright Trace Viewer. Демонстрація виявляє, що hover-стан поводиться інакше на headless CI runner, а сторінка може зберігати неочікуваний authorization state. Тимчасовий fix перевіряється повним smoke-командним запуском, але нез’ясована причина shared state прямо залишається окремою проблемою, а не оголошується остаточно виправленою. Smoke suite має падати рано й зупиняти беззмістовний regression run, якщо застосунок не завантажився або критичний flow зламаний. Якщо smoke зелений, а regression масово червоний, критерії smoke треба переглянути.
Test job повторює підготовку середовища, встановлює Chromium для Playwright і запускає pytest з відповідними markers. Smoke, regression, API та UI перевірки повинні мати явні набори запуску; в міру зростання проєкту їх краще рознести по окремих workflow, якщо вони мають різні triggers, dependencies або час виконання. Markers треба переглядати як продуктову класифікацію, а не разове маркування: smoke suite має залишатися малим і відповідати на питання, чи застосунок узагалі придатний до глибшої перевірки. Regression містить ширше покриття й не повинен блокувати ранній feedback від smoke.
Fix комітиться й повторно запускається в pull request. Linter і smoke можуть стартувати паралельно, щоб базова функціональна перевірка не чекала на завершення статичного аналізу; точна залежність між jobs визначається вимогами проєкту. Після оновлення п’ять smoke tests проходять. Практичний цикл завершено повним ланцюжком: CI failure → artifact → локальний Trace Viewer → вузька зміна → повторний зелений smoke run.
Для OTP можна зарезервувати test identity і детермінований code; для rate limits — окреме правило для CI traffic. Автор допускає такий bypass навіть на production, хоча прямо зазначає, що цього бажано не робити. Редакційне security-застереження: на production безпечніше виконувати smoke через звичайний захист або спеціально спроєктований найменш привілейований test path. Будь-який production bypass header чи hardcoded OTP стає критичним секретом: його витік фактично вимикає захист, тому потрібні ротація, журналювання, вузький scope і окремий security review.
У спрощеній моделі Playwright спочатку запускає browser process, потім створює ізольований `BrowserContext`, а в ньому — одну або кілька `Page`. Launch options стосуються процесу браузера, context options — сесії користувача, cookies, permissions та емуляції, а `Page` представляє вкладку й виконує дії зі сторінкою. Через `channel="chrome"` можна запустити встановлений branded Chrome замість bundled Chromium. Це потрібно, коли поведінка залежить від повного браузера або медіакодеків; для більшості перевірок швидшого bundled Chromium достатньо. Маркери дають змогу виконувати `smoke` і `regression` окремо. Практичний CI flow: спочатку короткий smoke suite перевіряє, що середовище придатне до тестування, і лише після нього запускається довша regression suite.
Після переходу на `uv` набори запускаються через `uv run pytest` і pytest markers на кшталт `smoke` або `regression`. Перший context виконує login та записує state, наступні contexts завантажують цей файл. Перевірка показує, що оптимізація не виправляє помилки очікувань автоматично: тест може падати через неправильний `is_loaded` або інший homepage state. Треба відрізняти проблему повторної авторизації від помилки самої fixture чи assertion.
Після падіння smoke job у її artifacts знаходиться архів із traces. Його завантажують і переносять у локальний проєкт або тимчасову директорію для аналізу. Trace відкривається командою `playwright show-trace`, яку можна викликати через інструмент керування Python-середовищем проєкту.
У `pytest.ini` задаються каталоги з тестами, шаблони імен тестових файлів і функцій та директорії, які не потрібно сканувати. Це звужує test discovery до структури проєкту й прибирає зайву роботу з `.git`, `.idea`, build-артефактами та кешами. Через `addopts` виносяться параметри, які мають застосовуватися до кожного запуску: verbose output, короткий traceback, відображення output лише для failed tests, strict markers, Playwright tracing і генерація self-contained HTML report. Маркери `smoke`, `regression`, `web` та `slow` реєструються явно, щоб помилка в назві не перетворилася на тихе пропускання потрібної групи. Для traces обирається `retain-on-failure`: артефакт створюється під час тесту, але зберігається лише після падіння. Це практичніший default, ніж trace для кожного успішного тесту, бо архіви можуть швидко зайняти багато місця.
CLI встановлюється як системний інструмент, а `allure-pytest` додається до Python dependencies. Pytest налаштовується зберігати машинні результати в `allure-results`; цю директорію не комітять. Smoke і regression jobs завантажують свої `allure-results` як artifacts. Publish job завантажує їх, встановлює сумісну версію Allure CLI та виконує `allure generate`. Старі Playwright HTML artifacts можна прибрати, якщо Allure справді стає єдиним report і не втрачає потрібної діагностики. Версії CLI, Python binding і pytest adapter мають залишатися сумісними. Їх не слід незалежно оновлювати без pipeline verification, бо format results і генератор розвиваються окремо.
Повторювані checkout, setup `uv`, setup Python та install dependencies винесено у локальний composite action. Input `install-playwright` вмикає браузерні залежності лише для jobs, яким вони потрібні. Це виправдане перевикористання, бо той самий setup уже виконується в smoke і regression jobs. Після тестів workflow завантажує HTML report і Playwright traces як artifacts. Для них задається retention, наприклад 14 днів: це тимчасові діагностичні результати, а не постійне сховище. HTML report зберігається завжди, traces — переважно після failure.