Відеобібліотека
Пошук у нотатках курсу 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 →Пояснює upload/download artifacts, retention і передачу test outputs між jobs.
2. Практика та написання пайплану CI/CD → Першоджерело ↗Trace, logs і reports можуть містити credentials, tokens, test source або application source. Зберігайте їх лише в trusted artifact store або encryption-protected share; local show-trace є простішою межею для чутливих artifacts.
3. Фікс трейсів на СІ →Фіксує поточний flow configure, upload і deploy для Pages artifacts.
2. Практика та написання пайплану CI/CD → Першоджерело ↗В окремому навчальному repository додайте правила для .venv/, .env і test results.
Перевірте кожен path через git check-ignore -v.
Задайте local user.name і user.email, потім перевірте їх через git config --list --show-origin.
Команди перевірки та staged diff, у якому немає .env і generated artifacts.
Publish job завантажує report artifacts і deploys GitHub Pages.
Поточний official Pages flow вимагає configure-pages, upload-pages-artifact і deploy-pages; deploy job має needs, pages: write, id-token: write, environment github-pages і може повертати canonical page_url.
Поточний contract перевірено 2026-07-31; одна дата зміни не встановлена.
2. Практика та написання пайплану CI/CD →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 і генератор розвиваються окремо.
Файли зберігають підготовлених users, transactions або результати, які треба передати наступному кроку чи додати до report. Перед записом варто визначити життєвий цикл даних: тимчасовий debug output не повинен назавжди засмічувати repository або CI agent.
Запуск простої команди `pytest` у терміналі відтворює спосіб, у який suite згодом стартуватиме на CI. Така перевірка важлива: запуск через IDE може мати інший working directory, environment або власні параметри. `pytest-html` створює початковий звіт зі статусами тестів і доступними логами. Його достатньо для першої діагностики на CI: знайти failed test, переглянути повідомлення, а потім локально відтворити проблему з trace. Звіт не замінює повну observability, але дає мінімальний переносний артефакт. Каталоги з HTML-звітами, screenshots і traces додаються до `.gitignore`. Це результати конкретного запуску, а не вихідний код; їх треба публікувати як CI artifacts, а не комітити в репозиторій.
Повторювані 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.
Trace для кожного успішного тесту швидко збільшує обсяг CI artifacts. Простий варіант «зберігати все» допустимий для малого набору з коротким retention, але кращий контракт — залишати ZIP лише коли тест упав. Артефакт має жити достатньо, щоб інженер устиг провести root-cause analysis. Retention і upload налаштовуються на рівні CI; сама fixture відповідає лише за локальне створення файлу.
Після падіння smoke job у її artifacts знаходиться архів із traces. Його завантажують і переносять у локальний проєкт або тимчасову директорію для аналізу. Trace відкривається командою `playwright show-trace`, яку можна викликати через інструмент керування Python-середовищем проєкту.
Python dictionary можна серіалізувати через `json.dumps(user, indent=2)` і записати як UTF-8 text. JSON зручний для API-like data, бо зберігає field names і вкладену структуру. Не слід записувати tokens, passwords або персональні дані в artifacts без явної потреби й захисту.
[Дивитися з 10:20](https://www.youtube.com/watch?v=reaHS8_pZbU&t=620s). Стабільного інженера часто цінують вище за «rockstar», який коротко дає надрезультат, але має підвищений ризик burnout. Якщо automation або AI скоротили виконання задачі, час можна вкласти в навчання, сім’ю, відпочинок чи власний small product, а не автоматично збільшувати обсяг sprint commitment. Окремий варіант — локальний analyzer для test failures, artifacts або code review, який бере контрольований фрагмент logs/code, формує summary і допомагає знайти напрямок виправлення. Такий інструмент має залишатися в дозволеній trust boundary. Дві повні зайнятості автор згадує лише як короткостроковий спосіб заробітку й не радить його як тривалий режим через навантаження та ризик вигорання.
Розробники можуть використовувати ШІ для unit-тестів і швидких прототипів, а QA — для чернеток тестової стратегії, тест-плану, тест-кейсів та автотестів. Бізнес-аналітики й продуктова команда можуть залучати його ще на refinement, коли вартість виправлення нечіткої вимоги значно нижча. Найбільший резерв іноді не в генерації коду, а в кращому плануванні фічі: описати ризики, підготувати тікети, визначити спосіб перевірки й повернутися до best practices або технічного боргу, на які раніше не вистачало часу. Корисне впровадження є комплексним: змінюються не лише інструменти окремого розробника, а й спосіб взаємодії ролей у SDLC.
Business зазвичай цікавить, чи можна продемонструвати й продати ключовий flow, чи стабільний продукт і чи не блокують bugs інвестиції або клієнтів. Формат внутрішньої документації другорядний, доки він допомагає команді передбачувано delivery-ити результат. Додаткові process artifacts стають виправданими, коли зменшують реальну проблему: часті incidents, втрату domain knowledge, складний onboarding або неоднозначні requirements. Сам по собі Gherkin не виправляє низьку якість implementation чи відсутність coverage.