Відеобібліотека
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
GitHub попереджає, що код workflow на self-hosted runner може скомпрометувати машину та доступні secrets. Один runner виконує одну job одночасно, але це не гарантує ізоляцію між послідовними jobs; для untrusted workflows потрібні ephemeral runners або інша isolation strategy.
Інфраструктура автотестів та її нюанси →Урок пропонує уявляти job як чистий container або окрему машину.
GitHub окремо визначає GitHub-hosted і self-hosted runners. Hosted job отримує fresh runner instance за documented contract, але environment не перетворює self-hosted runner на isolated container.
Перевірено за документацією 2026-07-31; точна дата зміни не встановлена.
1. Теорія CI/CD та як ви можете інтегрувати тести в пайплайн →Сервер, який виконує workflow job. GitHub надає hosted runners, а self-hosted runner керується власником інфраструктури.
1. Теорія CI/CD та як ви можете інтегрувати тести в пайплайн →Намалювати маршрут від runner до application і залежностей.
Зафіксувати потрібні credentials та мінімальні network rules.
Запустити suite з обраною concurrency й записати peak CPU/RAM.
Обґрунтувати hosted або self-hosted варіант фактичними даними.
Короткий capacity та access worksheet без універсальних припущень про RAM або вартість.
Набір steps, що виконується на одному runner; jobs за замовчуванням можуть виконуватися паралельно, якщо між ними не визначено залежність.
1. Теорія CI/CD та як ви можете інтегрувати тести в пайплайн →Фіксує поточні визначення workflow, job, step, action і runner.
1. Теорія CI/CD та як ви можете інтегрувати тести в пайплайн → Першоджерело ↗CI-інтерфейс не виконує тести сам: GitHub або інша система передає job конкретному runner. Це окрема машина чи контейнер, який має отримати репозиторій, інструменти, конфігурацію та мережевий доступ до системи під тестом. Hosted runner з публічного інтернету може не бачити DEV/STG, доступний лише через VPN або приватну мережу. Тоді потрібен self-hosted runner усередині інфраструктури або інше узгоджене мережеве рішення. Тому питання «де запускатимуться тести?» треба вирішувати разом із доступами, credentials і topology, а не після написання workflow.
Відкривати приватне середовище для широкого діапазону IP хмарного CI дорого в підтримці й збільшує поверхню атаки. Практичніший варіант — runner усередині контрольованої мережі: GitHub або GitLab передає йому job, а сам runner уже має потрібний маршрут до тестової інфраструктури. Доступ усе одно обмежують мережевими правилами й мінімальними правами конкретного runner.
Runner клонує репозиторій, встановлює або використовує залежності та запускає тестовий процес. UI-тести додатково піднімають один чи кілька браузерів; навіть headless browser споживає відчутну кількість RAM. Розмір runner слід визначати за реальною паралельністю, наборами браузерів і піковим споживанням, а не за вимогами звичайного application build.
Playwright має APIs для TypeScript/JavaScript, Python, Java і .NET. Найповніша інтеграція навколо власного runner, fixtures і reporting доступна у Playwright Test для TypeScript/JavaScript; у Python за orchestration зазвичай відповідає pytest та його plugins. Selenium також має офіційні language bindings, які перетворюють API-виклики на WebDriver commands. Окремі команди підтримують Selenium project і browser vendors, тому version compatibility та відмінності bindings залишаються частиною експлуатації. Обидва інструменти — великі multi-language ecosystems. Вибір мови впливає не лише на синтаксис, а й на доступність runner integrations, fixtures, reporters, tracing і швидкість появи нових можливостей.
Middle має володіти мовою настільки, щоб писати й підтримувати UI та API tests, а також пояснити, як перевірити нову поведінку й які наявні тести варто змінити. UI automation легше показує зв'язок із діями користувача, тоді як API automation часто швидша й стабільніша, але вимагає впевнено працювати з більшими структурами даних і контрактами. Очікується знання базових типів, перетворень і наслідків звуження/розширення типів, dependency/build tool свого stack (`requirements.txt`, `pip`/`uv`, Maven/Gradle, npm), а також можливостей test runner. Важливо вміти запустити тести паралельно й розуміти, які ресурси та змінні створюються для кожного worker.
Локально Selenium client, driver і browser часто знаходяться на одній машині, тому додаткові HTTP round trips майже непомітні. У remote topology команди можуть пройти від CI runner до Selenium Server/Grid, далі до remote node або cloud browser і назад. Polling explicit waits множить network latency на кількість перевірок. Географія також впливає на system behavior: CI runner, browser node і application backend у різних регіонах дають інший latency profile, ніж локальна машина. Тому green local run не доводить, що timeout достатній для Grid/BrowserStack. Remote suite треба перевірити до merge, а browser nodes за можливості розміщувати ближче до application environment. У Playwright очікування й action orchestration потребують менше client-side polling round trips, тому modern UI suite зазвичай працює швидше й стабільніше. Але запити самої сторінки до backend однаково залежать від мережі: Playwright не прибирає latency тестованої системи.
Повноцінний reporting — це додаткова система, яку доведеться оновлювати й підтримувати. Якщо команді достатньо logs, screenshots, traces і простого HTML report, не варто автоматично додавати Allure лише через популярність. Він доречний, коли потрібні історія, структуровані steps, attachments і спільна точка перегляду результатів. Екосистема має три практичні шари: Allure CLI генерує report; language binding формує сумісні result files; framework adapter на кшталт `allure-pytest` підключається до конкретного test runner. У відео також прямо згадано ризик telemetry та походження продукту: перед adoption треба перевірити актуальну політику даних і вимкнути необов’язкову аналітику відповідно до правил організації.
Selenium розглядається не як одна функція для керування браузером, а як екосистема. Для Python-тестів ключовим є Selenium WebDriver; Selenium IDE дає змогу записати простий сценарій у браузері й згенерувати початковий код, а Grid стосується розподіленого запуску. Залежність додається через `pip install selenium` або `uv add selenium`, після чого середовище треба синхронізувати. Допоміжний `pytest-selenium` може спростити старт, але урок застерігає від прив’язки до слабо підтримуваної обгортки: базову Selenium fixture нескладно контролювати самостійно. `pytest` залишається test runner незалежно від браузерної бібліотеки. Тому Selenium- і Playwright-тести можуть певний час співіснувати в одному Python-проєкті під час поступової міграції; їх достатньо розвести по зрозумілих packages, не переписуючи весь набір одразу.
GitHub і GitLab називають виконавців jobs runners, Jenkins — agents. Хмарні runners зручні, але в приватних організаціях хвилини виконання можуть тарифікуватися. Self-hosted runner працює всередині інфраструктури компанії, дає більше контролю над ресурсами й доступами та часто зменшує операційну вартість регулярних прогонів.
Workflow починається з назви та triggers. Для перевірки змін використовується `pull_request`, для регулярного прогону — `schedule`, а `workflow_dispatch` дозволяє запустити вибраний набір вручну. Scheduled run є прийнятним компромісом, коли deployment events або сам delivery pipeline ще нестабільні, але команді вже потрібен регулярний feedback. Перша job виконує checkout репозиторію, налаштовує `uv` і Python, встановлює dependencies, запускає Ruff та format check. Checkout обов’язковий, бо runner стартує без коду проєкту.