GitHub скорректировала дату полного применения минимальных требований к версиям self-hosted runners в GitHub Enterprise Cloud. Изменение выпускается 28 сентября 2026 года, а полное принудительное применение требований начнется 29 сентября.
Сами требования к версиям не пересматривались. Компания рекомендует обновить еще не переведенные на поддерживаемый выпуск раннеры до 29 сентября, чтобы избежать нарушений в работе GitHub Actions. Для команд, использующих self-hosted-инфраструктуру для сборки моделей, запуска тестов, развертывания агентов или других автоматизированных процессов, это означает необходимость проверить не только конфигурацию workflow, но и исполняющие их машины.
Обновление относится только к GitHub Enterprise Cloud. Инсталляции GitHub Enterprise Server под действие объявленного графика не попадают.
Две даты в обновленном графике
В сообщении GitHub Changelog указаны два этапа: выпуск изменения в понедельник, 28 сентября, и начало полного применения требований во вторник, 29 сентября 2026 года. Именно вторая дата является контрольным сроком для администраторов.
GitHub сообщает, что дата была изменена относительно прежнего объявления, однако в доступном сообщении не приводит предыдущий срок. Поэтому из публикации нельзя достоверно определить, насколько именно сдвинулся график и получила ли каждая организация существенную дополнительную отсрочку. Рассчитывать на продолжительный переходный период после 29 сентября также не следует.
Минимально допустимая версия раннера в кратком объявлении не названа. Ее необходимо сверять с актуальными данными GitHub, а не с внутренней инструкцией или сохраненной копией старой документации. Это особенно существенно для инфраструктуры, где разные группы машин обновляются независимо и могут использовать неодинаковые выпуски runner application.
Data Residency уже работает по новым правилам
Отдельный график действует для GitHub Enterprise Cloud с Data Residency. По данным GitHub, применение требований к версиям self-hosted runners для этого варианта сервиса началось 31 июля 2026 года.
Таким образом, дата 29 сентября не является новой отсрочкой для организаций с Data Residency: их инфраструктура уже находится под действием ограничений. Администраторам таких окружений стоит проверять текущий статус раннеров и журналы выполнения заданий, а не ориентироваться на сентябрьский срок.
GitHub Enterprise Server, напротив, объявление не затрагивает. Из этого не следует, что для серверной редакции автоматически установлен аналогичный будущий дедлайн: компания в данном сообщении такого графика не публиковала. Смешанным организациям, использующим одновременно облачные и локальные контуры, следует разделить инвентаризацию по типу платформы.
API помогает найти устаревающие раннеры до остановки задач
Для контроля версий GitHub предлагает REST API, через который можно получить даты прекращения регистрации и выполнения заданий для конкретной версии раннера. Эти два показателя стоит учитывать отдельно: ограничения на регистрацию экземпляра и на его дальнейшую работу могут вводиться в разные моменты.
Описание методов для администрирования раннеров доступно в документации REST API GitHub Actions. На базе получаемых данных команды могут настроить предупреждения для пулов, приближающихся к сроку прекращения поддержки.
Практический сценарий — регулярное задание, которое собирает версии раннеров по организациям и репозиториям, сопоставляет их с датами устаревания и отправляет уведомление владельцу соответствующего пула. Такой контроль полезен в средах, где раннеры распределены между несколькими командами, облачными учетными записями или изолированными сетевыми сегментами.
При этом наличие API само по себе не обновляет машины и не подтверждает готовность workflow к запуску после обновления. Автоматическое оповещение должно быть связано с конкретным процессом: назначением ответственного, заменой или обновлением экземпляра и последующей тестовой сборкой.
Что проверить в инфраструктуре до 29 сентября
Первым шагом должна стать полная инвентаризация self-hosted runners в GitHub Enterprise Cloud. Проверка только активных машин может пропустить временно выключенные экземпляры, резервные образы и автоматически создаваемые раннеры, которые позднее вернутся в пул со старой версией.
Администраторам имеет смысл выполнить следующие действия:
Собрать список раннеров на уровнях организации и репозитория, включая временно недоступные экземпляры.
2. Зафиксировать установленную версию runner application и владельца каждой группы машин.
3. Проверить даты устаревания через REST API и сопоставить их с внутренним графиком обновлений.
4. Обновить неподдерживаемые экземпляры по официальной документации по управлению self-hosted runners.
5. После обновления запустить тестовые workflow, использующие те же метки, права доступа, контейнеры и сетевые зависимости, что и рабочие задания.
6. Проверить шаблоны машин и образы автоскейлинга: обновление уже запущенного экземпляра не исправит устаревший базовый образ, из которого создаются новые раннеры.
7. Настроить предупреждения заранее, а не в день прекращения поддержки версии.
Для AI- и data-команд последствия могут выходить за рамки обычной сборки приложения. Через self-hosted runners нередко запускаются задачи с GPU, подготовка контейнеров, проверки моделей, публикация артефактов и развертывание внутренних сервисов. Если конкретный пул перестанет принимать задания, очередь может сохраниться на стороне GitHub Actions, но критический этап доставки продукта не будет выполнен вовремя.
GitHub не уточняет в коротком анонсе точный сценарий сбоя для каждой неподдерживаемой версии. Поэтому не стоит предполагать, что проблема ограничится предупреждением в интерфейсе. Безопасная контрольная точка — успешный тестовый запуск на обновленном раннере до 29 сентября, а для Enterprise Cloud с Data Residency — немедленная проверка уже действующих пулов.
