Відеобібліотека
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Workflow у відео окремо налаштовує uv і Python.
Поточний setup-uv може встановити Python через uv, тому actions/setup-python не є обов’язковим. Окремий setup-python може залишатися виправданим через runner tool cache.
setup-uv v9.0.0 перевірено 2026-07-31; точну дату появи Python management у цьому brief не встановлено.
2. Практика та написання пайплану CI/CD →GitHub Action, який встановлює uv і додає його до PATH; dependencies усе одно встановлюються окремою uv command, а Python може керувати сам uv.
2. Практика та написання пайплану CI/CD →Показує найкоротший workflow path від checkout до smoke tests без винесення setup у composite action.
Pull request або manual dispatch створює smoke job на ubuntu-latest і запускає pytest marker smoke.
2. Практика та написання пайплану CI/CD →Поточний installation guide показує uv add pytest-playwright як підтриманий варіант поряд із pip і Poetry; це додатковий workflow, а не вимога переписувати урок.
Фіксує Python target і мінімальний набір lint rules у canonical project file.
uv run ruff check . аналізує Python-файли за правилами репозиторію.
Фіксує current setup-uv contract, Python management і major version, використану в code-001.
2. Практика та написання пайплану CI/CD → Першоджерело ↗pip — базовий і простий інструмент, тоді як uv дає швидше встановлення, сучасніше керування проєктом і зручніші механізми для команд запуску та конфігурації. uv написаний на Rust і особливо помітно скорочує час відновлення залежностей у CI та після клонування репозиторію. Окрема перевага — робота з конфліктами транзитивних залежностей, коли дві бібліотеки очікують різні версії третьої. uv також дає чіткіший контроль за правилами оновлення й фіксації версій. Аналогія з Java: Maven виконує базову задачу, Gradle надає ширші можливості й за коректної конфігурації може швидше збирати проєкт. Але переваги нового інструмента треба пов’язувати з реальною проблемою команди, а не лише з його новизною.
Після переходу на `uv` набори запускаються через `uv run pytest` і pytest markers на кшталт `smoke` або `regression`. Перший context виконує login та записує state, наступні contexts завантажують цей файл. Перевірка показує, що оптимізація не виправляє помилки очікувань автоматично: тест може падати через неправильний `is_loaded` або інший homepage state. Треба відрізняти проблему повторної авторизації від помилки самої fixture чи assertion.
Замість ручної послідовності створення `venv`, активації та `pip install -r requirements.txt` проєкт переходить на `uv sync`. Залежності й метадані описуються у `pyproject.toml`, а `uv.lock` фіксує точні версії, включно з транзитивними залежностями. Для застосунку або тестового проєкту lock-файл варто комітити: це відтворює однаковий dependency graph локально та в CI й зменшує ризик конфліктів, коли різні бібліотеки вимагають несумісні версії спільної залежності.
Після зміни залежностей запускається `uv sync`, а фактично встановлена версія звіряється з lock-файлом. Якщо імпорт не працює або підтягнулась неочікувана версія, спочатку треба перевірити синхронізацію середовища, а не змінювати тестовий код навмання. Створюється pytest fixture, яка ініціалізує `webdriver.Chrome()` і повертає driver тесту. Команди тесту надходять до browser driver, а він уже керує браузером. Аналогічно можна створювати Firefox, Edge або Safari driver, але для навчального сценарію достатньо Chrome. Сучасний Selenium Manager підбирає сумісний driver автоматично, тому за звичайного локального запуску не потрібно вручну завантажувати executable й прописувати шлях. Це спрощує fixture, але версії Selenium і браузера все одно мають залишатися відтворюваними в CI.
Переписувати весь test suite з нуля зазвичай не потрібно. Коли старий тест зламався або нову задачу значно легше реалізувати новим засобом, її можна зробити на uv чи Playwright і залишити робочі старі тести на pip або Selenium. В одному репозиторії тимчасово можуть співіснувати: - pip і uv; - Maven і Gradle; - Selenium і Playwright; - pytest та інший test runner; - JUnit і TestNG. CI просто виконує окремі команди для відповідних наборів. Основний ризик — не саме співіснування, а конфлікти спільних транзитивних залежностей і додаткова вартість підтримки двох стеків. Найбезпечніший аргумент для міграції — конкретна користь на конкретному сценарії: швидше встановлення, простіша діагностика, потрібне мокання network або стабільніша робота з браузером. Після доказу підхід можна розширювати.
Після міграції тест запускається через команду `uv run ...` з консолі, бо це ближче до майбутнього CI-запуску, ніж Run Configuration IDE. Треба перевірити, що виконався потрібний тест і що очікуване падіння справді належить тестовій логіці, а не відсутній залежності чи неправильному шляху. Фінальний крок — створити короткий `README` з мінімальною версією Python, установкою, командами запуску, структурою та правилами внесення змін. Commit message перевіряється вручну: він має називати реальну міграцію на `uv` і підключення Ruff, а не перелічувати випадкові деталі diff.
Middle має володіти мовою настільки, щоб писати й підтримувати UI та API tests, а також пояснити, як перевірити нову поведінку й які наявні тести варто змінити. UI automation легше показує зв'язок із діями користувача, тоді як API automation часто швидша й стабільніша, але вимагає впевнено працювати з більшими структурами даних і контрактами. Очікується знання базових типів, перетворень і наслідків звуження/розширення типів, dependency/build tool свого stack (`requirements.txt`, `pip`/`uv`, Maven/Gradle, npm), а також можливостей test runner. Важливо вміти запустити тести паралельно й розуміти, які ресурси та змінні створюються для кожного worker.
Selenium розглядається не як одна функція для керування браузером, а як екосистема. Для Python-тестів ключовим є Selenium WebDriver; Selenium IDE дає змогу записати простий сценарій у браузері й згенерувати початковий код, а Grid стосується розподіленого запуску. Залежність додається через `pip install selenium` або `uv add selenium`, після чого середовище треба синхронізувати. Допоміжний `pytest-selenium` може спростити старт, але урок застерігає від прив’язки до слабо підтримуваної обгортки: базову Selenium fixture нескладно контролювати самостійно. `pytest` залишається test runner незалежно від браузерної бібліотеки. Тому Selenium- і Playwright-тести можуть певний час співіснувати в одному Python-проєкті під час поступової міграції; їх достатньо розвести по зрозумілих packages, не переписуючи весь набір одразу.
Workflow починається з назви та triggers. Для перевірки змін використовується `pull_request`, для регулярного прогону — `schedule`, а `workflow_dispatch` дозволяє запустити вибраний набір вручну. Scheduled run є прийнятним компромісом, коли deployment events або сам delivery pipeline ще нестабільні, але команді вже потрібен регулярний feedback. Перша job виконує checkout репозиторію, налаштовує `uv` і Python, встановлює dependencies, запускає Ruff та format check. Checkout обов’язковий, бо runner стартує без коду проєкту.
Повторювані 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.