Три проверки зависшего pipeline
- Если job в очереди, сравните
runs-on, labels, группу runner и его доступность для репозитория. - Если job уже стартовал, проверьте конкретный шаг, runtime action и совместимость runner, не смешивая это с проблемой очереди.
- После исправления выполните тестовую сборку и безопасный выпуск без рабочих платежей, писем и вебхуков.
Условная карточка приёмки показывает, что нужно подтвердить на каждом этапе.
| Этап | Проверка | Запись о результате |
|---|---|---|
| Runner | Online, labels совпадают, очередь принята | ID runner и время старта job |
| Job | Шаги закончились без ошибки и ожидаемых пропусков | Run ID, commit SHA, результат шагов |
| Build | Артефакт создан из нужного commit | Имя и checksum артефакта |
| Тестовый выпуск | Критичный сценарий работает, откат проверен | Среда, сценарий, результат и версия отката |
Зелёный job не подтверждает работу сайта после выкладки. Результат восстановления CI/CD — эта цепочка подтверждений и список оставшихся ограничений.
Сентябрьские сроки ниже — исторический контекст. Если читаете позже, проверьте текущие требования в официальной документации, версию установленного runner и журнал своего запуска; прошедшая дата сама по себе не доказывает причину сбоя.
Сборка сайта висит в очереди, хотя разработчик уже подготовил исправление? Сначала определите, получил ли задание собственный исполнитель GitHub Actions — self-hosted runner. Если задание ещё не назначено, проверяют доступность исполнителя, его версию и правила назначения; если выполнение началось, ищут первый упавший шаг. Такая развилка помогает сохранить путь выпуска изменений и не менять рабочий сайт наугад.
Кому это актуально
Материал для руководителя веб-проекта, у которого сборка, тесты или выкладка зависят от собственного сервера GitHub Actions. Задание сборки здесь называется job, а описанная в репозитории последовательность заданий — workflow.
Особенно полезна проверка, если ответственный за сервер сменился, образ давно не пересобирали или обновления отключили. На исполнителях GitHub-hosted инфраструктуру обслуживает GitHub: описанные ниже проверки собственного хоста к ним не относятся.
Какие сроки проверить в сентябре 2026 года
По опубликованному расписанию GitHub Enterprise Cloud временно ограничивает регистрацию и выполнение заданий на устаревших исполнителях 14, 16 и 18 сентября. Полное применение требований запланировано на 25 сентября. Для Enterprise Cloud with Data Residency отдельный этап начался 31 июля; к GitHub Enterprise Server это объявление пока не относится. Даты и область действия указаны в официальном графике GitHub.
Порог регистрации — версия runner 2.329.0 — не является постоянной допустимой версией для выполнения заданий. Установленный исполнитель должен получать каждый новый релиз в пределах 30 дней; при критическом исправлении безопасности назначение заданий могут остановить раньше. Ориентир — актуальные требования на день проверки.
Отдельное изменение касается Node.js, среды выполнения JavaScript. GitHub перенёс удаление Node.js 20 из runner на 23 сентября 2026 года. Это дата из редакционного обновления от 25 августа; старые памятки с 16 сентября устарели. Основание — объявление о переходе Actions на Node.js 24.
Совпадение сбоя с датой ограничения — повод проверить версию, а не готовый диагноз. Очередь также может ждать свободного исполнителя, разрешения на запуск или подходящего окружения.
Как локализовать сбой без изменений на рабочем сайте
Начните с одного зависшего задания и ближайшего успешного запуска того же workflow. Зафиксируйте время, этап остановки и ожидаемый результат: например, появление новой сборки на тестовом сайте. Сравнивайте одинаковый сценарий, иначе различия настроек легко принять за причину аварии.
Задание не назначено исполнителю
В настройках GitHub Actions проверьте состояние runner и условия выбора в runs-on. Сопоставьте нужные метки, группу исполнителей и доступ репозитория к ней. Уточните, есть ли свободная машина: занятый исполнитель и недоступный исполнитель требуют разных действий.
Затем проверьте версию приложения runner и предупреждения GitHub. При отключённом автообновлении понадобится дата последнего обновления образа или установки. Не добавляйте метки случайному серверу ради старта задания: у него могут оказаться другие сетевые доступы и права.
Исполнитель недоступен
Ответственный администратор проверяет, работает ли служба, доступна ли сеть и проходит ли соединение с GitHub. Полезно сопоставить начало сбоя с обслуживанием хоста, изменением прокси или сертификатов.
Для обращения достаточно обезличенного фрагмента ошибки и времени. Полные журналы, конфигурации и значения секретов не нужны. Проверку сертификатов нельзя отключать ради восстановления соединения.
Задание началось и упало на конкретном шаге
Запишите первый шаг с ошибкой: получение кода, установка зависимостей, тест, сборка или выкладка. Если код ещё не получен, замена библиотек приложения пока не объясняет сбой. Если сборка готова, а выкладка не прошла, отдельно проверяют её разрешения и целевую среду.
Уточните, что изменилось между успешным и неудачным запуском: action, образ, настройки или версия программы. Это список проверяемых гипотез; сам факт обновления не доказывает причинную связь.
Где здесь Node.js
Разделите три компонента: приложение runner, среду JavaScript actions и Node.js самого проекта. Обновление одного компонента не подтверждает совместимость остальных. Параметр node-version в actions/setup-node выбирает версию для команд проекта, но сам action тоже имеет собственную среду выполнения — это видно в документации setup-node.
Поэтому ответственному нужно сверить требования выбранных actions и проверить сборку проекта в согласованном окружении. Переводить рабочий сервис на другую основную версию Node.js только из-за предупреждения Actions не следует: такое обновление требует отдельной проверки зависимостей.
Какие риски закрывает проверка
Главный риск для бизнеса — готовое исправление формы, оплаты или интеграции не удаётся выпустить. Второй риск возникает при попытке срочно обойти сломанную автоматизацию: теряется понимание, какая сборка установлена и как вернуться к предыдущей.
Проверка полезна, когда оставляет воспроизводимый результат. Предлагаем такой порядок приёмки:
- Ответственный подтверждает совместимость runner, операционной системы и используемых actions.
- Согласованный workflow получает задание на ожидаемом исполнителе и доходит до конца.
- Создаётся сборка с известной версией кода, которую можно однозначно связать с запуском.
- Эта сборка устанавливается в изолированную тестовую среду без отправки реальных заявок и платежей.
- Проверяется критичный маршрут: например, вход, получение данных и сохранение изменения на тестовой записи.
- На тестовой среде проверяется возврат к предыдущей сборке и доступность необходимых для него инструментов.
Это предлагаемые критерии приёмки, а не универсальная гарантия отсутствия ошибок. Зелёный статус задания подтверждает только выполненные внутри него проверки. Если workflow не проверяет результат установки, одного этого статуса недостаточно.
Что запросить у подрядчика
Попросите краткую карточку релизного процесса. Её можно заполнить без копирования секретов:
- Назначение: какой сайт или сервис собирается и какой workflow за него отвечает.
- Исполнитель: кто обслуживает runner, как он обновляется и когда пересобирают образ.
- Точка отказа: задание не назначено, не началось или остановилось на конкретном шаге.
- Подтверждённая причина: какое наблюдение отличило её от остальных гипотез.
- Результат проверки: версия сборки, тестовая среда, пройденный пользовательский маршрут.
- Возврат: как восстановить предыдущую сборку, если этот runner недоступен.
- Следующий контроль: кто и когда проверит обновляемость ещё раз.
Для типовой ситуации «исправление готово, но тестовый сайт показывает старую версию» полезно запросить связку «версия кода → сборка → установленная версия». Она покажет, дошло ли изменение до нужной среды. Этот пример иллюстрирует способ проверки и не описывает клиентский кейс.
FAQ
Можно ли дождаться 25 сентября?
Дату стоит использовать как границу планирования, а не как обещание работы до неё. В графике уже есть временные ограничения, а требования к актуальности runner действуют отдельно. Сначала установите, затронуто ли ваше окружение.
Достаточно включить автообновление?
Нужно также убедиться, что обновление действительно проходит, и повторить тестовый выпуск. Наличие настройки само по себе не показывает состояние операционной системы, actions и сборки приложения.
Если используется GitHub-hosted runner, вопрос закрыт?
Проверка собственного хоста отпадает, но выбранные actions, версия Node.js проекта и путь установки сборки остаются частью ответственности команды. При сбое начинайте с первого неуспешного шага.
Когда можно справиться своей командой?
Если есть ответственный за runner, актуальный образ, тестовая среда и проверенный порядок возврата, команда может провести обновление и приёмку сама. Внешняя помощь полезна при неизвестном окружении, повторяющихся сбоях или отсутствии безопасного способа проверить выпуск.
Как это решает OpenStart
OpenStart принимает существующие Node.js-проекты после диагностики: разбирает код, зависимости, логи и процесс выкладки, затем согласует этап работ. Этот формат описан на странице поддержки Node.js-приложений. Для конкретного runner сначала нужно выяснить границы задачи; сроки и результат нельзя обещать до знакомства с окружением.
Если собственная команда упёрлась в эти ограничения, в запросе на диагностику достаточно описать, что должно выпускаться, на каком этапе остановилось задание и когда был последний успешный запуск. Следующий шаг — уточнение состава проверки и необходимых доступов по согласованному каналу. Секреты и полные журналы в первичное обращение добавлять не нужно.