Self-hosted runners reference
Фіксує поточні властивості, routing і responsibility model self-hosted runners.
Інфраструктура автотестів та її нюанси → Першоджерело ↗Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Терміни, нюанси та джерела
Choosing the runner for a job
Уточнює відмінність GitHub-hosted і self-hosted runners та contract runs-on.
1. Теорія CI/CD та як ви можете інтегрувати тести в пайплайн → Першоджерело ↗Deployments and environments
Пояснює environments, protection rules, variables, secrets і межу isolation self-hosted runners.
1. Теорія CI/CD та як ви можете інтегрувати тести в пайплайн → Першоджерело ↗Runner
Сервер, який виконує workflow job. GitHub надає hosted runners, а self-hosted runner керується власником інфраструктури.
1. Теорія CI/CD та як ви можете інтегрувати тести в пайплайн →Self-hosted runner не є isolation boundary
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 та як ви можете інтегрувати тести в пайплайн →CI runners, agents і вартість виконання
GitHub і GitLab називають виконавців jobs runners, Jenkins — agents. Хмарні runners зручні, але в приватних організаціях хвилини виконання можуть тарифікуватися. Self-hosted runner працює всередині інфраструктури компанії, дає більше контролю над ресурсами й доступами та часто зменшує операційну вартість регулярних прогонів.
Швидка перевірка реального масштабу досвіду
Якщо кандидат описує CI pipeline, parallelization, sharding, self-hosted runners і підготовку database state перед deployment, окреме базове опитування синтаксису може не додати сигналу. Натомість interviewer просить пояснити, як саме було реалізовано рішення, які trade-offs виникли й що кандидат робив особисто.
Коли інтегрувати автотести в CI
Теза «тести без CI нікому не потрібні» занадто категорична. На ранньому етапі локальний запуск поруч із розробником може дати швидший і корисніший feedback, особливо коли deployment pipeline, runners або доступи ще нестабільні. Спочатку команда має довіряти тестам і вміти швидко зрозуміти причину падіння за report, trace, screenshot чи video. Довгі або нестабільні suites не можна бездумно ставити на критичний шлях hotfix deployment: зайняті runners і нестача ресурсів створять чергу для всієї команди. CI-інтеграцію варто нарощувати після того, як визначено мету набору, тривалість, стабільність і місце його запуску.
Мережевий доступ і self-hosted runners
Відкривати приватне середовище для широкого діапазону IP хмарного CI дорого в підтримці й збільшує поверхню атаки. Практичніший варіант — runner усередині контрольованої мережі: GitHub або GitLab передає йому job, а сам runner уже має потрібний маршрут до тестової інфраструктури. Доступ усе одно обмежують мережевими правилами й мінімальними правами конкретного runner.
Від build до deployment
Типовий delivery flow складається з отримання dependencies, компіляції або збирання застосунку, створення Docker image, завантаження versioned artifact до Artifactory чи іншого registry та deployment конкретної версії на середовище. Збережені версії дають змогу не просувати несправний build і повернутися до попереднього артефакту. Різні jobs можуть виконуватися на різних runners: один збирає застосунок, інший запускає system tests, третій виконує scheduled processing. Спеціалізація корисна, коли потрібні різні доступи або ресурси, але додає черги й інфраструктурні обмеження.
Спільні основи різних мов
Після першої мови наступна засвоюється швидше, бо основні задачі повторюються: прочитати або записати file, пройти collection, зберегти structured data, виконати network request, звернутися до database й запустити test runner. Змінюються syntax, libraries та окремі runtime semantics. Практичний орієнтир: добре вивчити одну мову на реальних задачах, а другу брати тоді, коли вона відкриває дешевший або надійніший спосіб вирішити поточну проблему. AI допомагає швидше знайти syntax, але не замінює перевірку architecture і behavior.
Публікація report у GitHub Pages
Окрема 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 показано, але конкретні нестабільні тести потребують подальшого розбору.