GitHub Actions и self hosted runners с 25 сентября

25 сентября 2026 года GitHub Enterprise Cloud начинает полное применение новых требований к версиям self hosted runners. Если runner слишком старый, он может перестать регистрироваться или получать новые workflow jobs.

Для команд со своими CI машинами это не косметическое обновление. Нужно проверить не только установленную версию runner, но и шаблоны VM, контейнерные образы, автоматическое обновление и сценарии восстановления после пересоздания runner.

GitHub заранее провёл серию brownout окон в августе и сентябре. Последние из них завершились 18 сентября, поэтому до полного enforcement осталось несколько дней.

Что изменится 25 сентября

Для регистрации нового или пересозданного runner требуется версия 2.329.0 или новее. Но этот номер не является постоянным минимальным уровнем для выполнения jobs.

GitHub отдельно сохраняет правило обновления в течение 30 дней после выхода новой версии runner. Если этот срок пропущен, сервис может перестать ставить jobs в очередь для такого runner. При критическом security update постановка jobs может быть остановлена до установки обновления.

Изменение относится к GitHub Enterprise Cloud. GitHub Enterprise Server на текущем этапе этим enforcement не затронут.

Почему версии 2.329.0 недостаточно навсегда

Версия 2.329.0 нужна как минимальная точка для регистрации на новой архитектуре Actions. После этого runner всё равно должен оставаться достаточно свежим для выполнения workflow.

Если автоматические обновления включены и runner имеет доступ к сервису обновлений, обычный runner обновляется сам. Если используется собственный образ или параметр --disableupdate, ответственность за регулярное обновление остаётся на владельце инфраструктуры.

Безопасная схема обновления runner fleet

ИнвентаризацияНайти все активные runners и определить их версии
ОбразыПроверить VM templates и container images из которых создаются runners
ОбновлениеПеревести runner на поддерживаемую версию и сохранить автоматический механизм обновлений
ТестЗапустить обычный workflow на каждом типе runner
КонтрольСледить за annotations и новыми runner releases

Главный принцип обновлять нужно не только уже запущенную машину, но и источник из которого она будет пересоздана.

Где чаще всего остаётся старая версия

в образе виртуальной машины который давно не пересобирался
в контейнере для ephemeral runner
в installation script с закреплённой старой ссылкой
в autoscaling template который создаёт новые runners из старого snapshot
на сервере где отключено автоматическое обновление

Особенно опасна ситуация когда работающий runner уже обновился, а шаблон для нового экземпляра остался старым. После перезапуска инфраструктуры проблема появляется снова.

Как проверить fleet перед enforcement

GitHub рекомендует обновить self hosted runners до актуальной поддерживаемой версии, проверить installation scripts и пересобрать старые образы и templates.

Для Enterprise Cloud также можно использовать audit log. События регистрации runner содержат его версию. Это помогает увидеть устаревшие экземпляры, хотя сам audit log не является полным инвентарём всех подключённых runners.

Чек лист до 25 сентября

все runners зарегистрированы на поддерживаемых версиях
в контейнерных и VM образах нет старого runner package
installation scripts не закреплены на устаревшей версии
автоматическое обновление работает там где оно разрешено
для --disableupdate есть отдельный процесс регулярного обновления
обычные workflow jobs проходят на каждом типе runner
есть понятный способ быстро пересоздать runner после сбоя

Что произойдёт с устаревшим runner

Слишком старая версия может не пройти регистрацию или повторную регистрацию. Уже подключённый runner который вышел за допустимое окно обновления может перестать получать jobs.

На практике это выглядит как CI проблема, хотя исходный код и workflow YAML не менялись. Jobs остаются в очереди или не находят подходящий runner, поэтому диагностику стоит начинать с версии и состояния runner fleet.

Как встроить обновление в CI инфраструктуру

Если runners создаются автоматически, версию лучше контролировать в одном месте. Это может быть Dockerfile, Packer image, cloud init шаблон или собственный installation script.

После изменения версии полезно прогонять минимальный тестовый workflow. Он должен проверить checkout репозитория, доступ к нужным tools, секретам и сети, а затем завершиться на новом runner без ручного вмешательства.

Если GitHub Actions уже используется для деплоя, можно отдельно разобрать автоматизацию GitHub Actions и связать обновление runners с существующим процессом CI. Для более широких сценариев подходит автоматизация бизнес процессов.

Частые вопросы

Достаточно ли поставить 2.329.0

Для регистрации эта версия является минимальной точкой, но для дальнейшего выполнения jobs runner нужно продолжать обновлять.

Что будет если автоматические обновления выключены

Runner нужно обновлять вручную и укладываться в требуемое окно после каждого релиза.

Затронет ли это GitHub Enterprise Server

Нет. В текущем объявлении GitHub отдельно указывает что GitHub Enterprise Server не входит в этот enforcement.

Нужно ли пересобирать контейнерные runners

Если образ содержит старую версию runner, его нужно обновить. Иначе новый контейнер снова поднимется со старым package.

Как понять что проблема именно в версии runner

Проверьте annotations workflow, версию runner, audit log регистрации и шаблон из которого runner создаётся.

Официальные источники

Если self hosted runners участвуют в production deploy и непонятно какие образы или scripts нужно обновить, можно прислать текущую схему A.S Groups. Сначала проверю точки запуска и обновления, затем предложу безопасный порядок изменений без остановки рабочего CI.

Следующий шаг