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 стартує без коду проєкту.

name: tests
on:
  pull_request:
  workflow_dispatch:

jobs:
  smoke:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@11d5960a326750d5838078e36cf38b85af677262
      - uses: astral-sh/setup-uv@c771a70e6277c0a99b617c7a806ffedaca235ff9
      - run: uv sync --frozen
      - run: uv run playwright install --with-deps chromium
      - run: uv run pytest -m smoke

Test job повторює підготовку середовища, встановлює Chromium для Playwright і запускає pytest з відповідними markers. Smoke, regression, API та UI перевірки повинні мати явні набори запуску; в міру зростання проєкту їх краще рознести по окремих workflow, якщо вони мають різні triggers, dependencies або час виконання.

Markers треба переглядати як продуктову класифікацію, а не разове маркування: smoke suite має залишатися малим і відповідати на питання, чи застосунок узагалі придатний до глибшої перевірки. Regression містить ширше покриття й не повинен блокувати ранній feedback від smoke.

Багато CI-систем встановлюють стандартну environment variable CI. Проєкт читає її, щоб увімкнути CI-специфічні налаштування: headless browser, відсутність локального video recording або іншу політику traces. Це дозволяє зберегти один кодовий шлях із мінімальною конфігураційною різницею.

Зміни комітяться й пушаться в task branch, після чого результат перевіряється не лише за загальним статусом, а й за logs конкретної job.

Повторювані 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.

Перед CI-запуском переглядаються pytest markers: частина тестів переноситься зі smoke до regression, окремо позначаються API, web і Selenium paths. Після відкриття pull request треба ще раз перевірити diff, reviewers і checks, щоб випадково не опублікувати зайві файли або credentials.

Перший pipeline закономірно знаходить lint і formatting problems. Їх виправляють локально тими самими командами, що виконує CI, комітять і повторюють запуск. CI тут є відтворюваною перевіркою, а не заміною локального feedback loop.

Після зеленого linter smoke tests падають. Рекомендований порядок діагностики: відтворити точну pipeline-команду локально, звузити запуск до suite, а потім до одного тесту. Якщо тест проходить окремо, але падає у suite, треба шукати shared state, порядок виконання, fixture scope або неповне очищення browser context.

Локальний і CI runner також відрізняються потужністю, швидкістю, браузерним режимом і доступами. Тому timeout або race condition може проявлятися лише на одній машині. Logs і artifact trace важливіші за припущення про причину.

Завантажений trace відкривається через Playwright Trace Viewer. Демонстрація виявляє, що hover-стан поводиться інакше на headless CI runner, а сторінка може зберігати неочікуваний authorization state. Тимчасовий fix перевіряється повним smoke-командним запуском, але нез’ясована причина shared state прямо залишається окремою проблемою, а не оголошується остаточно виправленою.

Smoke suite має падати рано й зупиняти беззмістовний regression run, якщо застосунок не завантажився або критичний flow зламаний. Якщо smoke зелений, а regression масово червоний, критерії smoke треба переглянути.

Окрема 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 показано, але конкретні нестабільні тести потребують подальшого розбору.