Відеобібліотека
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
GitHub і GitLab називають виконавців jobs runners, Jenkins — agents. Хмарні runners зручні, але в приватних організаціях хвилини виконання можуть тарифікуватися. Self-hosted runner працює всередині інфраструктури компанії, дає більше контролю над ресурсами й доступами та часто зменшує операційну вартість регулярних прогонів.
Для запуску Python-тестів у CI потрібно відтворити ті самі базові дії, що й локально: отримати код, встановити Python і залежності, окремо встановити браузери Playwright, запустити lint/format checks та потрібний набір тестів. `pipeline` описує весь процес, а `stage`, `job` і `step` — його менші етапи; точна вкладеність і назви залежать від GitHub Actions, GitLab CI, Jenkins, TeamCity, Bamboo чи іншої системи. Найпоширеніший декларативний формат — YAML. Він дає змогу зберігати pipeline поруч із кодом і однаково описувати послідовність команд, образ середовища, залежності між jobs та умови запуску без окремої мови програмування для кожного CI-продукту.
Відкривати приватне середовище для широкого діапазону IP хмарного CI дорого в підтримці й збільшує поверхню атаки. Практичніший варіант — runner усередині контрольованої мережі: GitHub або GitLab передає йому job, а сам runner уже має потрібний маршрут до тестової інфраструктури. Доступ усе одно обмежують мережевими правилами й мінімальними правами конкретного runner.
Якщо repository вже існує на GitHub, GitLab чи Bitbucket, правильний початок — `Git Clone`, а не повторна публікація. З Git hosting копіюється HTTPS або SSH URL, в IDE обирається локальна папка, після чого проєкт клонується. GitHub Desktop може виконати ту саму операцію, але відео демонструє вбудовані IDE-інструменти.