Runner groups
Тема дорожной карты · GitHub Actions
Группы runner'ов в GitHub Actions — это конструкция уровня организации или предприятия, разделяющая self-hosted runner'ы на именованные пулы и контролирующая, какие репозитории или workflow могут планировать на них задания. Создав группу runner'ов production-deploy и предоставив к ней доступ только определённым репозиториям, вы гарантируете, что комбинация меток runs-on: [self-hosted, production-deploy] не будет захвачена посторонним проектом для доступа к привилегированной инфраструктуре. Группы runner'ов поддерживают политики доступа, списки разрешённых workflow для публичных репозиториев и scoping видимости, интегрирующийся с GitHub Enterprise SSO. Использование групп runner'ов как границы безопасности обязательно, когда self-hosted runner'ы имеют облачные учётные данные, доступ к сети или ключи деплоя.
Как это работает
Runner groups runners работают на ваших машинах (VM, bare metal, k8s). Установите actions-runner пакет; зарегистрируйте через токен. Тегайте runners labels (self-hosted, linux, gpu) — workflows матчатся. Авто-скейл пулов runner через actions-runner-controller (k8s), runs-on.com или Philips Labs/terraform-aws-github-runner. Self-hosted runners получают полный доступ к репо — никогда не расшаривайте между недоверенными проектами.
Когда применять
Self-hosted — когда: сборки требуют GPU/special hardware, доступа к приватным ресурсам по сети, дольше 6 часов, большой compute дешевле cloud-квот, или compliance запрещает публичные облака. Для РФ self-hosted на Yandex Cloud / Selectel / локальной инфре — практичный выбор; GitHub-hosted могут быть медленны или недоступны. Авто-скейл или гибернация idle-runners.
Типичные ошибки
Ловушки Runner groups: self-hosted runner расшарен между публичными репо и приватным кодом (PR из публичного форка pwn-ит runner); runners никогда не патчатся (уязвимая поверхность); runners остаются online + принимают jobs откуда угодно (дефолт — ограничьте через runner_group); нет cleanup между jobs (state утекает).