Відеобібліотека
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Створіть workflow з pull_request і workflow_dispatch.
Запустіть lint та smoke в окремих jobs.
Збережіть report завжди, а traces — після failure.
Навмисно зламайте один smoke test і пройдіть шлях від job log до локального trace.
Випишіть типи даних, які workflow передає provider.
Позначте secrets, PII, customer data, proprietary code та contractual restrictions.
Для кожного типу визначте allowed provider, redaction, retention і approval owner.
Не запускайте workflow, доки blocking policy questions не закриті.
Data-flow checklist із дозволом або явною забороною для кожного типу даних.
Поточна офіційна документація описує planner, generator і healer для Node.js Playwright Test у TypeScript-first workflow. Playwright Test також підтримує JavaScript, а Python docs мають окремий Node-based playwright-cli для coding agents; це не той самий planner/generator/healer workflow.
Зміну після запису не встановлено: Playwright Test Agents з’явилися у v1.56 до сесії 2026-01-07; current docs checked 2026-07-31.
Оцінка корисності у відео залишається авторською думкою, але твердження про можливості інструмента треба показувати поруч із актуальним official state.
Неймінг та структура automation-проєкту →Показує найкоротший workflow path від checkout до smoke tests без винесення setup у composite action.
Pull request або manual dispatch створює smoke job на ubuntu-latest і запускає pytest marker smoke.
2. Практика та написання пайплану CI/CD →Дозволена межа даних, providers і controls для AI workflow, визначена governance, privacy, security та contractual requirements організації.
Як працювати на спокійному проєкті та з нав’язаними оцінками →Файл або набір файлів, створений під час workflow run і збережений GitHub для обміну між jobs або подальшого завантаження.
2. Практика та написання пайплану CI/CD →Workflow починається з назви та triggers. Для перевірки змін використовується `pull_request`, для регулярного прогону — `schedule`, а `workflow_dispatch` дозволяє запустити вибраний набір вручну. Scheduled run є прийнятним компромісом, коли deployment events або сам delivery pipeline ще нестабільні, але команді вже потрібен регулярний feedback. Перша job виконує checkout репозиторію, налаштовує `uv` і Python, встановлює dependencies, запускає Ruff та format check. Checkout обов’язковий, бо runner стартує без коду проєкту.
[Дивитися з 02:15](https://www.youtube.com/watch?v=reaHS8_pZbU&t=135s). AI може прискорити механічний refactoring, роботу з CI pipelines, Docker images, reporting, logs і повторюваними змінами. Цінність виникає не від підписки як такої, а від знайденого repeatable workflow: зібрати потрібний context, виконати вузьку задачу, перевірити diff і зберегти лише підтверджений результат. У відео звучить порада приховувати AI use через CLI та локальні ignore rules, якщо client його забороняє. Це ризикована практика: відсутність desktop app не робить передачу даних невидимою для network/security controls і не скасовує contractual restrictions. Без explicit approval не можна передавати proprietary code, secrets, logs або customer data зовнішньому provider. Безпечний шлях — узгоджений tool, дозволений data scope, redaction і локальний/offline workflow там, де це справді відповідає policy.
У демонстрації виправляється помилка з назвою `.ignore`: для Git потрібен саме `.gitignore`. Схожий суфікс використовують й інші інструменти у власних файлах, наприклад `.cursorignore`, але кожен із них має окреме призначення. Рекомендований стартовий workflow: ініціалізувати Git-репозиторій, створити `.gitignore`, одразу записати відомі локальні каталоги на кшталт `.idea/`, `.venv/` і результатів тестів, а вже потім індексувати потрібні вихідні файли. IDE може запитувати, чи автоматично додавати новостворені файли до Git; це зручно, якщо ignore-правила вже захищають локальні артефакти.
Спроба вивести URL через `run` у неправильному місці YAML ламає workflow schema, і GitHub відхиляє конфігурацію ще до тестів. Команду переносять усередину валідного step. IDE plugin і GitHub validation допомагають ловити такі структурні помилки до або одразу після push. Фінальний мінімальний ланцюжок: pytest створює `allure-results`, test jobs передають їх як artifacts, publish job генерує site, GitHub Pages розміщує report, а Playwright traces поки зберігаються окремо як надійний diagnostic artifact.
Repository-level secrets доступні workflow всього репозиторію, тоді як environment secrets можна обмежити конкретним оточенням і його protection rules. Workflow явно посилається на потрібні значення, тому конфігурація стає частиною контракту запуску, але самі секрети не з’являються у YAML. Кожну job варто уявляти як чистий контейнер або машину на базі визначеного image, наприклад `ubuntu-latest`. Наступне практичне відео показує, як на такому runner послідовно виконати checkout, setup, install і tests.
[Дивитися з 00:00](https://www.youtube.com/watch?v=crzGm6nzfbU&t=0s). Агент описується як окремий запуск Claude Code, Codex або іншого CLI з конкретною роллю: PM, architect, backend developer, researcher, designer, QA automation чи test analyst. Його файл визначає доступні tools, модель, пам'ять, permission mode, обов'язкові джерела контексту, workflow, формат артефактів і hard rules. Найважливіша частина — що агент мусить прочитати на кожному запуску та за яких передумов може починати роботу. Чим сильніша модель, тим менше їй потрібно дрібних підказок, але межі відповідальності й незмінні заборони все одно треба записати явно.
[Дивитися з 00:00](https://www.youtube.com/watch?v=viR9Rnmxse4&t=0s). Для кожного модуля потрібно не лише переглянути матеріал, а повторити показане, додати новий test або покращити попередній. Основним practice surface є тестове середовище YOY: тут можна створювати users, communities та events. Production для автоматизації не підходить, зокрема через CAPTCHA й ризик забруднення реальних даних.
Test job повторює підготовку середовища, встановлює Chromium для Playwright і запускає pytest з відповідними markers. Smoke, regression, API та UI перевірки повинні мати явні набори запуску; в міру зростання проєкту їх краще рознести по окремих workflow, якщо вони мають різні triggers, dependencies або час виконання. Markers треба переглядати як продуктову класифікацію, а не разове маркування: smoke suite має залишатися малим і відповідати на питання, чи застосунок узагалі придатний до глибшої перевірки. Regression містить ширше покриття й не повинен блокувати ранній feedback від smoke.
CI-інтерфейс не виконує тести сам: GitHub або інша система передає job конкретному runner. Це окрема машина чи контейнер, який має отримати репозиторій, інструменти, конфігурацію та мережевий доступ до системи під тестом. Hosted runner з публічного інтернету може не бачити DEV/STG, доступний лише через VPN або приватну мережу. Тоді потрібен self-hosted runner усередині інфраструктури або інше узгоджене мережеве рішення. Тому питання «де запускатимуться тести?» треба вирішувати разом із доступами, credentials і topology, а не після написання workflow.
Перед комітом створюється нова гілка. Для командної роботи назва починається з ідентифікатора задачі з Jira, Linear або іншої системи, а далі містить короткий опис. Це пов’язує код з конкретною роботою й спрощує пошук історії. Навіть у сольному проєкті гілки дозволяють відкласти незавершену задачу, повернутися на `main` і почати іншу, не змішуючи зміни.