Відеобібліотека
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
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 →Artifact зі статичними файлами сайту, який передається deployment job для публікації через GitHub Pages.
2. Практика та написання пайплану CI/CD →Trace, logs і reports можуть містити credentials, tokens, test source або application source. Зберігайте їх лише в trusted artifact store або encryption-protected share; local show-trace є простішою межею для чутливих artifacts.
3. Фікс трейсів на СІ →Перший рядок розпаковує лише зовнішній artifact; другий передає внутрішній trace.zip Playwright CLI.
Відкривається Trace Viewer для конкретного failed test.
3. Фікс трейсів на СІ →Мінімальна послідовність для browser tests у CI: checkout, Python/dependency setup, встановлення browser dependencies, запуск pytest і збереження diagnostic artifact.
2. Практика та написання пайплану CI/CD →Trace містить actions, DOM snapshots, console і network details; це корисний debugging artifact, який може містити чутливі headers або payloads.
Як упровадити автоматизацію мануальному QA та довести її ефективність →Окрема publish job завантажує artifacts, створені smoke/regression jobs, готує Pages artifact і виконує deployment. Artifact є мостом між runners: файл, створений однією job, не з’являється автоматично на машині іншої job. У repository settings джерелом Pages обирається GitHub Actions, а environment `github-pages` отримує правила deployment, сумісні з task branches. Наприкінці workflow ще має test failures, тому урок завершується чесною межею: механізм pipeline і Pages показано, але конкретні нестабільні тести потребують подальшого розбору.
Після падіння smoke job у її artifacts знаходиться архів із traces. Його завантажують і переносять у локальний проєкт або тимчасову директорію для аналізу. Trace відкривається командою `playwright show-trace`, яку можна викликати через інструмент керування Python-середовищем проєкту.
Artifact може бути ZIP-архівом, усередині якого лежать окремі `trace.zip`. Archive Utility на macOS рекурсивно розпаковує вкладені архіви й змінює очікувану структуру, після чого Trace Viewer не розпізнає результат як trace. Надійніший шлях — розпакувати зовнішній artifact консольною командою `unzip` у визначену директорію та передати Trace Viewer внутрішній `trace.zip` без повторного пакування. Пробіли в шляху треба екранувати або передавати шлях одним quoted argument.
На enterprise-проєктах доступ до публічних package registries часто обмежують. Дозволені бібліотеки та внутрішні збірки зберігають у корпоративному artifact repository або пропускають через контрольований proxy. Такі сховища дають версіонування, allowlist і сканування вразливостей. Якщо зовнішній пакет не дозволений, команда або погоджує його через встановлений процес, або реалізує мінімально потрібну поведінку самостійно — хоча власний код теж має вартість підтримки й не є автоматично безпечнішим.
Модалки для Test і Suite мають схожий заголовок та форму. Спільний helper параметризується `artifact_type`, але лише там, де це справді одна поведінка; різні postconditions залишаються окремими й читабельними. Після Save suite перевіряється за її назвою у списку. Демонстрація кілька разів падає через переплутані helpers і case-sensitive текст `Suite`, що показує цінність короткого red/green циклу для кожного locator.
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 і генератор розвиваються окремо.
Fix комітиться й повторно запускається в pull request. Linter і smoke можуть стартувати паралельно, щоб базова функціональна перевірка не чекала на завершення статичного аналізу; точна залежність між jobs визначається вимогами проєкту. Після оновлення п’ять smoke tests проходять. Практичний цикл завершено повним ланцюжком: CI failure → artifact → локальний Trace Viewer → вузька зміна → повторний зелений smoke run.
[Дивитися з 10:30](https://www.youtube.com/watch?v=viR9Rnmxse4&t=630s). Щотижня очікується один або кілька нових tests. Перша домашня робота публікується як repository link; наступні — в окремих branches і pull requests порівняно з `main`. Це дає reviewer-у точний diff конкретного модуля, а учневі — невеликий, але реальний portfolio artifact. Якщо PR уже merged, треба чітко вказати commit або зміни, які відповідають домашній роботі.
Типовий delivery flow складається з отримання dependencies, компіляції або збирання застосунку, створення Docker image, завантаження versioned artifact до Artifactory чи іншого registry та deployment конкретної версії на середовище. Збережені версії дають змогу не просувати несправний build і повернутися до попереднього артефакту. Різні jobs можуть виконуватися на різних runners: один збирає застосунок, інший запускає system tests, третій виконує scheduled processing. Спеціалізація корисна, коли потрібні різні доступи або ресурси, але додає черги й інфраструктурні обмеження.
Повторювані 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.