Self-hosted GitHub Actions runner не получает jobs: что проверить до ограничений 2026 года

Сборка висит в очереди, self-hosted runner отображается как Offline или релиз внезапно перестал получать jobs, хотя код проекта не менялся. Для организаций на GitHub Enterprise Cloud это особенно актуально перед 24 августа 2026 года: GitHub планирует начать временные brownout-проверки устаревших runners, а полное применение новых требований запланировано на 25 сентября 2026 года.

Параллельно GitHub Actions переводит JavaScript actions с Node.js 20 на Node.js 24. Это два разных слоя риска: версия приложения runner влияет на получение jobs, а версия runtime — на выполнение checkout, сборки, тестов и деплоя. Проверять их нужно раздельно, иначе легко обновить workflow и оставить без внимания устаревший сервер сборки.

Если job остаётся в очереди, не переводите релиз на ручной запуск вслепую. Сначала сохраните диагностику и убедитесь, что причина не связана с версией runner, метками, правами или связью с GitHub.

Что меняется в августе и сентябре 2026 года

GitHub сообщил, что для GitHub Enterprise Cloud временные ограничения начнутся 24 августа. Сначала устаревшие runners могут периодически не регистрироваться; в следующие недели brownout затронет и выполнение jobs. Полное применение требований заявлено на 25 сентября 2026 года.

Точный минимальный номер версии меняется вслед за релизами runner. Поэтому недостаточно один раз обновиться до номера из старой инструкции. По официальной документации self-hosted runner с отключённым автообновлением нужно обновлять не позднее чем через 30 дней после выхода любой новой версии. При критическом исправлении безопасности GitHub может перестать ставить jobs в очередь до обновления.

Автообновление по умолчанию относится только к приложению GitHub Actions Runner. Оно не обновляет операционную систему, Docker, Node.js, системные библиотеки и инструменты сборки. Даже runner со свежим приложением может не пройти следующий релиз из-за старой ОС или несовместимого окружения.

Кому это актуально

Проверка нужна командам, которые запускают GitHub Actions на собственных Linux-, Windows- или macOS-хостах, в виртуальных машинах, контейнерах или Kubernetes. Приоритет особенно высок, если runner участвует в:

• выкладке сайта или API в production;
• миграциях базы данных;
• сборке Next.js, Node.js, React или мобильного приложения;
• подписании и публикации мобильных сборок;
• доступе к закрытой сети, CRM, оплате или внутренним сервисам;
• сборке Docker-образов и работе с секретами окружения.

GitHub-hosted runners обслуживает сам GitHub, а self-hosted инфраструктуру поддерживает владелец проекта. Если ответственный за сервер ушёл, документации нет или обновления отключены ради стабильности образа, риск пропустить ограничение выше.

Как понять, почему runner не получает jobs

1. Проверить статус и область подключения

В настройках репозитория или организации откройте Settings → Actions → Runners. Статус Offline означает, что приложение runner не связано с GitHub: хост может быть выключен, служба остановлена или исходящее соединение недоступно. Статус Idle говорит только о готовности runner; job всё равно может не назначаться из-за меток, группы, прав доступа или требований версии.

Зафиксируйте имя runner, область регистрации, метки и текущее состояние. Не публикуйте в тикете токен регистрации, содержимое секретов или полный конфигурационный файл.

2. Сопоставить runs-on и метки

Workflow может ждать бесконечно, если в runs-on указана метка, которой нет ни у одного доступного runner. Проверьте регистр, архитектуру, операционную систему, группу runner и разрешение конкретному репозиторию использовать эту группу.

Изменять метки наугад опасно: job может уйти на хост без нужной сети, Docker, сертификатов или прав для деплоя. Сначала восстановите ожидаемую схему маршрутизации.

3. Проверить версию и режим обновления

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

Проверьте журналы в каталоге _diag: в них видно попытки автообновления, соединение с GitHub и ошибки запуска jobs. Для контейнерных ephemeral runners важно обновить базовый образ, а не надеяться на загрузку обновления при каждом старте.

4. Проверить службу, сеть и ресурсы

Runner должен быть запущен как служба и иметь исходящее HTTPS-соединение с GitHub. Дополнительно проверьте свободное место, каталог _work, права сервисного пользователя, Docker daemon и доступ к registry. Ошибка диска или Docker может проявляться уже после назначения job, тогда как проблема связи оставляет runner в Offline.

Не отключайте проверку TLS ради быстрого обхода. Если соединение перехватывает корпоративный proxy, корректнее установить доверенный сертификат и проверить разрешённые домены.

5. Найти последнее успешное выполнение

Сравните последний успешный job и первый зависший: версию runner, образ, runs-on, commit workflow, используемые actions и системные обновления. Такая граница помогает отличить изменение GitHub от локального сбоя сервера.

Как здесь связан Node.js 24

Версия приложения runner и версия Node.js для проекта — не одно и то же. GitHub уже переводит JavaScript actions на Node.js 24, поэтому устаревший сторонний action может начать выдавать предупреждения или перестать выполняться даже на свежем runner.

Отдельно закрепите версию Node.js, на которой собирается сам проект: через actions/setup-node, Docker-образ, .node-version, Volta или другой управляемый механизм. Она должна совпадать с поддерживаемой версией production либо входить в заранее проверенную матрицу совместимости.

Перед изменением релизного контура проверьте:

• официальные и сторонние actions в .github/workflows;
• install, build, test и lint на целевой версии Node.js;
• нативные зависимости и lock-файл;
• сборку Docker-образа и публикацию артефактов;
• deploy на staging и план отката;
• контрольные сценарии сайта после выкладки: формы, авторизацию, оплату, CRM и API.

Один зелёный job не подтверждает готовность CI/CD. Важно пройти весь маршрут от commit до проверенного изменения на staging и убедиться, что rollback не зависит от того же сломанного runner.

Какие риски закрывает проверка

Плановое обновление снижает риск ситуации, когда важное исправление готово, но не может попасть в production. Для бизнеса это означает:

• меньше задержек с исправлением заявок, оплаты и интеграций;
• сохранение повторяемого деплоя вместо ручных команд;
• контроль доступа runner к production и секретам;
• предсказуемое обновление Node.js и сторонних actions;
• возможность отката после неудачной сборки;
• понятную ответственность за серверы CI/CD.

Self-hosted runner — привилегированная часть инфраструктуры. Не регистрируйте новый хост поверх старого, пока не проверены права, секреты, рабочие каталоги и сетевой доступ.

Что запросить у подрядчика

Результатом работы должно быть не сообщение «runner обновлён», а проверяемый релизный контур. Попросите передать:

• перечень runners, их назначение, владельца и режим обновления;
• версии приложения runner, ОС, Docker и Node.js без раскрытия секретов;
• карту runs-on, labels и runner groups;
• список workflows, которые выкладывают изменения в production;
• результаты тестового job и staging-деплоя;
• правила ротации образов и контроля 30-дневного окна обновлений;
• журналы проверки без токенов и персональных данных;
• план отката и действия на случай Offline или очереди jobs;
• дату следующей плановой проверки.

Как это решает OpenStart

OpenStart начинает с инвентаризации CI/CD: какие runners существуют, что они собирают, как маршрутизируются jobs, где закреплены версии Node.js и какие workflows имеют доступ к production. Затем команда отделяет проблему приложения runner от ОС, Docker, Node.js, сторонних actions и настроек репозитория.

Для Node.js, Next.js и API-проектов можно заказать проверку и поддержку Node.js-контура. Если runner обслуживает несколько сайтов, CMS и интеграций, задачу разумно включить в регулярную техническую поддержку вместе с мониторингом релизов и критичных пользовательских сценариев.

Цель диагностики — вернуть не один job, а управляемый путь выпуска изменений: с ответственным, staging, журналами, smoke-тестами и откатом. Такой процесс снижает зависимость от конкретного сервера и одного специалиста.

FAQ

Устаревший runner обязательно перестанет работать 24 августа?

Не обязательно в первый день. 24 августа GitHub планирует начать временные brownout-проверки для GitHub Enterprise Cloud, а полное применение требований заявлено на 25 сентября. Конкретное поведение зависит от версии и этапа проверки, поэтому обновление лучше провести заранее.

Если включено автообновление, можно ничего не проверять?

Нет. Автообновление касается приложения runner, но не ОС, Docker, Node.js и инструментов сборки. Кроме того, журнал обновления и последний успешный job всё равно стоит контролировать.

Почему runner Idle, а job остаётся в очереди?

Частые причины — несовпадение runs-on и labels, ограничения runner group, отсутствие доступа у репозитория или требования версии. Статус Idle подтверждает связь, но не гарантирует назначение конкретного job.

Нужно ли сразу переносить сборку на GitHub-hosted runner?

Не всегда. Self-hosted runner нужен для закрытых сетей, специального оборудования или собственного окружения. Сначала стоит восстановить обновляемость, документировать доступы и проверить, действительно ли собственный хост остаётся оправданным.

Можно ли обновить только Node.js?

Нет. Обновление Node.js не обновляет приложение runner, и наоборот. Нужно проверить оба слоя, а также ОС, Docker, actions и весь путь деплоя.

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

Если релизные jobs стали зависать или runner давно не обновлялся, зафиксируйте статус, версию, labels и последнее успешное выполнение. OpenStart может провести диагностику CI/CD, подготовить безопасный план обновления и проверить staging-деплой до того, как ограничение затронет срочный релиз.

Источники

• GitHub Actions: сроки применения минимальных версий self-hosted runners
• GitHub Docs: требования и обновления self-hosted runners
• GitHub Changelog: переход GitHub Actions с Node.js 20

---

Служебный блок для редактора

• Автор: blog-agent OpenStart.
• Экспертная проверка: ожидается в редакционном процессе.
• Дата последней проверки: 20.08.2026.
• Целевой запрос: «self-hosted GitHub Actions runner не получает jobs».
• Тип поискового намерения: problem-first, информационно-коммерческий.
• Цель доверия: reduce_risk, show_process, show_expertise.
• Связанные услуги: поддержка Node.js-проектов, техническая поддержка сайтов и сервисов.
• Связанные кейсы: не использовались.
• Использовались ли внутренние данные OpenStart: нет.
• Источник внутренних данных: не использовался.
• Статус проверки фактов: ready_for_review; даты и требования сверены с официальными материалами GitHub 20.08.2026.
• Публичные целевые страницы проверены 20.08.2026: /services/nodejs и /support отвечают 200.