Миграция GitHub Actions Node 24: чек-лист обновления Mac CI в 2026 году

По данным официального уведомления GitHub о прекращении поддержки Node 20, временный режим обратной совместимости действует только до 23 сентября 2026 года. Поэтому миграцию GitHub Actions Node 24 не следует откладывать до окончательного удаления Node 20: уже сейчас нужно включить Node 24 на изолированном Mac-узле, проверить Action, Runner, macOS и полный конвейер Xcode, а затем переводить production-пул партиями. Старые узлы, которые нельзя обновить, следует вывести из production или заменить новым удалённым Mac.

Кому нужен этот план

Материал предназначен для платформенных команд, управляющих self-hosted runner и Mac CI, чтобы старый runtime или версия Runner не остановили сборки.

Он также пригодится командам, выпускающим iOS-приложения: нужно проверить Xcode, подпись, кеши и собственные Action до допуска Node 24 в production.

IT-руководителям план помогает заранее определить объём замены Mac, правила отката и требования к дополнительным изолированным узлам.

Важно: Node 24 внутри JavaScript Action, версия Node.js проекта и версия приложения Actions Runner — три разные сущности. Обновление одного компонента не доказывает совместимость двух остальных.

Последняя проверка сроков: что должно быть готово до дедлайна

На 2 сентября 2026 года GitHub подтверждает следующую последовательность: с 16 июня 2026 года Actions Runner по умолчанию использует Node 24, а Node 20 остаётся временным вариантом до 23 сентября 2026 года. Для self-hosted runner в GitHub Enterprise Cloud плановое массовое принудительное выполнение минимальной версии начинается 25 сентября 2026 года. Даты и точные требования могут уточняться, поэтому перед переключением необходимо сверить официальную временную шкалу минимальной версии Runner и фактическую версию на странице загрузки организации.

Это не означает, что каждый workflow сразу перестанет работать. Риск возникает там, где JavaScript Action ещё ссылается на старый runtime, Runner не удовлетворяет минимальному условию или окружение macOS не поддерживает требуемую версию приложения. Проект, который сам устанавливает Node.js через setup-node, не заменяет runtime, на котором исполняется Action.

Что именно нужно различать

• Runtime Action: встроенная среда, в которой запускается JavaScript Action, например actions/checkout или собственный Action команды.
• Node.js проекта: версия, под которой собирается приложение, запускаются тесты или выполняется JavaScript-инструмент проекта.
• Actions Runner: служебное приложение, принимающее задания, подготавливающее рабочую директорию и передающее команды macOS.
• macOS и CPU-архитектура: системные условия узла, влияющие на совместимость Runner, Xcode, SDK, сертификатов и сторонних бинарных зависимостей.

Первый день: составьте карту Action, Runner и Mac

До изменения production необходимо собрать не общий список серверов, а связку «репозиторий — workflow — Action — узел». Минимальная инвентаризация должна включать:

• репозиторий и название workflow;
• используемые версии Action и способ их фиксации;
• self-hosted runner и его labels;
• версию приложения Runner;
• версию macOS;
• архитектуру CPU;
• установленные версии Xcode;
• наличие приватных зависимостей, сертификатов и signing identity;
• кеши, прокси, корпоративные сертификаты и пользовательские shell-скрипты.

Справочник self-hosted runner описывает базовые свойства и labels, которые используются для маршрутизации заданий. Для автоматической инвентаризации можно запросить список runner через REST API self-hosted runner, а историю сбоев сопоставить с данными REST API workflow runs.

Минимальный фрагмент для получения списка узлов должен использоваться только из административного окружения с нужными правами:

gh api orgs/ORG/actions/runners \
  --paginate \
  --jq '.runners[] | [.name, .os, .status, .busy, (.labels | map(.name) | join(","))] | @tsv'

Затем к каждому workflow следует добавить результат проверки: какая строка использует Action, какие шаги работают на Mac CI, какой узел выполняет задание и был ли fallback на Node 20. Предупреждение в журнале важнее предположения по названию Action: одна и та же версия может запускаться по-разному после обновления зависимостей.

Какие workflow могут сломаться после отключения Node 20? В первую очередь те, где JavaScript Action явно или косвенно требует старый runtime, а также задания на узлах с устаревшим Runner. Обычный run: node ... относится к Node.js проекта и проверяется отдельно. Поэтому список риска формируется по логам Action, предупреждениям GitHub и состоянию узла, а не по наличию слова Node в YAML.

В первые 60 минут: запустите Node 24 на изолированном узле

Для пилота выбирается Mac без production-сертификатов подписи и без доступа к секретам выпуска. На нём заранее фиксируются текущие версии Runner, macOS, Xcode, инструменты пакетного менеджера и сетевые настройки. Такой узел должен иметь те же labels и максимально близкий набор инструментов, что и будущий production-пул, иначе тест окажется формальным.

GitHub предоставляет механизм раннего включения нового runtime. Перед применением необходимо сверить актуальное имя миграционной переменной и порядок её использования в официальном уведомлении, поскольку временные параметры могут изменяться вместе с программой перехода. Включение следует делать на уровне пилотного задания или тестовой группы, а не сразу для всей организации.

Базовый workflow должен пройти минимум следующие этапы:

1. получение репозитория через checkout;
2. восстановление и сохранение кеша;
3. установка зависимостей;
4. запуск собственного JavaScript Action;
5. сборка и тесты;
6. упаковка и загрузка тестового артефакта.

Нельзя считать совместимость подтверждённой только потому, что компиляция завершилась успешно. В журнале нужно сохранить название шага, exit code, версию Runner, системную информацию, использованный Xcode, результат кеширования и причину каждого отклонения.

Как проверить совместимость self-hosted runner с Node 24? Сначала запускается полный базовый workflow на узле, принудительно использующем Node 24, затем проверяются статус Runner, связь с GitHub, выполнение собственного Action и поведение после перезапуска службы. Версия приложения сверяется с актуальными релизами Actions Runner, а не только с версией, указанной в локальном имени каталога.

Первый рабочий день: обновите Action и сам Runner

После пилотного запуска исправления выполняются в порядке, который уменьшает неопределённость.

Сначала — Action и фиксации версий

Обновляются официальные и сторонние Action, которые используют старый runtime. Особое внимание требуется workflow с фиксацией на commit SHA: такая фиксация полезна для контроля цепочки поставок, но она не обновляется автоматически. Нужно определить новый проверенный SHA, повторить тест и внести изменение через review.

Собственные JavaScript Action проверяются на устаревшие зависимости, предположения о формате переменных окружения, обработку путей и сетевые вызовы. Если Action вызывает внешний бинарный файл, его совместимость с Node 24 не гарантируется самим обновлением JavaScript-кода.

Затем — Runner, служба и регистрация

Для каждого Mac Runner проверяются:

• доступность узла в организации или группе;
• состояние online после обновления;
• отсутствие задания, застрявшего во время замены;
• корректный запуск службы после перезагрузки;
• сохранение labels и Runner Group;
• отсутствие старого узла в production-маршрутизации.

Порядок настройки службы описан в официальной инструкции GitHub для self-hosted Runner. Автоматическое обновление не следует считать достаточным: после него нужен контроль версии, регистрации и пробного задания.

Если старый macOS не удовлетворяет условиям нового Runner, есть только три устойчивых варианта: обновить систему, заменить узел или исключить его из production-пула. Постоянное удержание fallback-переменной после контрольной даты создаёт ложное ощущение готовности и переносит сбой на момент принудительного отключения.

Сводка решения для разных узлов

Первая production-проверка: пройдите полный цикл Xcode

На этом этапе проверяется не абстрактная Mac CI-среда, а реальный путь поставки приложения. Тестовый workflow должен использовать безопасные тестовые credentials и по возможности не публиковать результат в production-канал.

Последовательность проверки:

1. получить исходный код и приватные зависимости;
2. установить зависимости в чистую рабочую директорию;
3. выбрать нужную схему и версию Xcode;
4. запустить unit-тесты и, если это часть стандартного процесса, UI-тесты;
5. создать archive;
6. выполнить подпись тестовым или ограниченным signing identity;
7. проверить экспорт артефакта;
8. загрузить артефакт в тестовое хранилище;
9. проверить контрольные суммы и доступность результата;
10. удалить временные ключи и рабочие данные после завершения.

В процессе фиксируются изменения поведения Keychain, security, прокси-сертификатов, кешей и shell-скриптов. Node 24 не обязан быть причиной каждого сбоя: смена Runner или очистка рабочей директории может проявить уже существующую зависимость от локального состояния.

Нужно ли одновременно обновлять macOS и Runner? Не всегда. Если текущая macOS поддерживает требуемый Actions Runner, сначала можно обновить Runner и протестировать workflow. Если система не поддерживает нужную версию Runner, одновременное обновление macOS становится условием допуска; при невозможности обновления узел не должен оставаться в production только ради временного Node 20.

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

Для процедурной стороны полезно заранее закрепить требования в документе о приёмке self-hosted Mac Runner и не смешивать его с общим тестом компиляции. Если команда использует отдельную схему изоляции signing-узлов, критерии доступа должны быть записаны до переключения, а не добавлены после первого сбоя.

Первая неделя: оставьте два пула и отработайте возврат

До завершения миграции сохраняются:

• проверенный production-пул с текущим маршрутом;
• отдельный Node 24-пул с labels или Runner Group;
• список репозиториев, допущенных к пилоту;
• владелец решения по каждому исключению;
• процедура удаления узла из маршрутизации.

Репозитории переводятся партиями. Сначала выбираются workflow без production-подписи, затем конвейеры с тестовой подписью, и только после подтверждения полного цикла — релизные задания. Если несколько проектов используют один Mac, переключение должно учитывать общую очередь: нельзя направить все команды на пилотный узел и затем трактовать задержку как ошибку Node 24.

Можно ли сохранить рабочий fallback для старого Mac Runner? Да, но только как временный, явно изолированный пул с ограниченным набором репозиториев и датой удаления. Он не должен получать новые production-секреты, а его labels нельзя оставлять в универсальном маршруте. После контрольной даты fallback не заменяет обновление: если Runner или macOS не соответствуют требованиям, узел выводится из production.

Необходимо провести четыре отказоустойчивых сценария:

1. JavaScript Action завершается ошибкой;
2. обновление Runner прерывается;
3. Mac перезагружается между заданиями;
4. недоступный узел приводит к перенаправлению задания на другой допустимый Runner.

Для каждого сценария фиксируются обнаружение, время восстановления, повторный запуск и состояние секретов. Если таких измерений ещё нет, нельзя обещать конкретную производительность или время восстановления: эти параметры зависят от проекта, сети, кешей и количества узлов и должны подтверждаться реальной проверкой конкретной организации.

При росте очереди IT-команда сначала сверяет фактическую загрузку и долю успешно прошедших пилот workflow, затем решает, нужен ли дополнительный Mac. Временное расширение разумнее планировать после выделения labels для Node 24, чтобы новые ресурсы не стали ещё одним непроверенным production-маршрутом. Если требуется отдельная машина для тестов, параметры аренды Mac можно сопоставить с периодом миграции на странице условий и доступных вариантов RUVCLOUD, не принимая коммерческое решение до проверки технической совместимости.

До принудительного срока: заморозьте исключения и подпишите допуск

К 23 сентября 2026 года у каждого workflow должен быть один из статусов:

• прошёл Node 24 и полный Xcode-цикл;
• ожидает конкретного исправления с назначенным владельцем;
• переведён во временный изолированный fallback;
• заблокирован до замены узла или обновления macOS.

К 25 сентября 2026 года нужно дополнительно сверить фактический план применения минимальной версии self-hosted Runner для конкретной организации. Организационная страница загрузки и Changelog имеют приоритет над старой внутренней документацией.

Производственный допуск удобно оформлять в виде чек-листа:

• [ ] версия Action проверена и не удерживается случайным старым commit;
• [ ] Node 24 протестирован на отдельном Mac;
• [ ] Runner обновлён, зарегистрирован и виден после перезапуска;
• [ ] macOS поддерживает допущенную версию Runner;
• [ ] приватные зависимости скачиваются в чистой рабочей директории;
• [ ] Xcode build и тесты завершены;
• [ ] archive, подпись и экспорт артефакта подтверждены;
• [ ] кеши и shell-скрипты проверены;
• [ ] production-секреты отсутствуют на пилотном узле до отдельного допуска;
• [ ] откат и повторная маршрутизация проверены;
• [ ] владелец, дата удаления fallback и план замены записаны.

Ответы на вопросы, которые возникают у закупки и эксплуатации

Что делать, если сторонний Action ещё не готов к Node 24? Сначала проверяется обновление, документация и закреплённая версия. Если Action остаётся несовместимым, его workflow временно оставляют в изолированном пуле, но создают срок исправления или замену Action. Перенос всего production на старый runtime не является долговременной стратегией.

Нужен ли Intel Mac для этой миграции? Сам факт перехода Node 24 не делает Intel-узел автоматически несовместимым. Решение принимается по поддержке Runner, macOS, Xcode, SDK и зависимостей проекта. Архитектуру нельзя заменять предположением: она должна быть отдельным полем инвентарной карты и частью реального теста.

Что делать, если обновление Runner не завершилось? Узел удаляется из production labels, проверяется служба, журналы и регистрация, затем выполняется ручное обновление по официальной процедуре. Если восстановление не подтверждено, задание направляется на уже принятый узел, а не на Mac с неопределённым состоянием.

Когда удалённый Mac оправдан как замена

После инвентаризации становится видно, какие Mac нельзя обновить до нужного Runner или macOS в установленный срок. Покупка нового оборудования может быть оправдана при длительной стабильной нагрузке, необходимости физических интерфейсов и контролируемом жизненном цикле устройства. Однако для короткого периода двойного пула у неё есть недостатки: закупка занимает время, ресурсы простаивают после миграции, а IT-команда получает дополнительные задачи по доставке, обслуживанию, дискам, доступу и удалённому восстановлению.

Текущая схема со старыми локальными узлами также сохраняет риск неодинаковых окружений, ручных обновлений и нехватки ёмкости во время параллельной проверки. В такой ситуации аренда удалённого Mac у RUVCLOUD может быть более управляемым промежуточным решением: сначала выделяется изолированный узел для Node 24, затем команда подтверждает реальный Xcode-процесс и только после этого определяет срок аренды и количество замен. Такой вариант не отменяет самостоятельную проверку безопасности и не подходит, если проекту постоянно нужны физические устройства или длительная предсказуемая тяжёлая нагрузка, но он позволяет не оставлять несовместимый Mac в production ради ожидания закупки. Для запуска пилотного узла можно изучить варианты заказа удалённого Mac у RUVCLOUD.

Главное решение для IT-команды простое: не ждать отключения Node 20, а уже сейчас разделить runtime Action, Node.js проекта и Runner, провести изолированный тест Node 24, доказать полный Xcode-цикл и заменить узлы, которые не проходят технические условия. Такой порядок превращает календарный дедлайн в управляемую миграцию с проверенным возвратом, а не в аварийную остановку iOS CI.