Что делать, если версия GitHub Actions Runner устарела? Чек-лист обновления Mac на 2026 год

Runner показывает статус «Online», но задания уже не выполняются или не принимаются. Самое быстрое решение — не ждать остановки очереди: автоматические узлы сразу проверить по официальным инструкциям, узел с отключённым автообновлением сначала прикрыть резервным Mac и обновлять через серую проверку, а пул узлов вести в три фазы — тест, расширение, откат.

Эта статья для личных разработчиков с единственным постоянно работающим Mac Runner, небольших команд, которые делят подпись, кеши и Xcode, а также платформенных и DevOps-команд с фиксированными версиями, ограниченной сетью или большим пулом узлов.

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

Почему устаревший Runner нельзя оценивать по статусу «Online»

Устаревшая версия GitHub Actions Runner и обычная ошибка рабочего процесса — разные классы проблем. В первом случае сам узел может оставаться зарегистрированным и отображаться онлайн, но платформа уже применяет требования к версии исполнения. В результате задание не будет принято, останется в очереди или завершится сообщением о необходимости обновления. Точный диапазон затронутых аккаунтов, уровней управления и дат нужно сопоставлять с официальной временной шкалой минимальной версии, а не с пересказом из форума.

Проверьте четыре объекта:

• тип аккаунта и уровень Runner — репозиторий, организация или Enterprise Cloud;
• версию, которую узел сообщает при регистрации и в журнале;
• включено ли автоматическое обновление;
• официальную заметку в интерфейсе, журнале или диагностике, а не только зелёный индикатор доступности.

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

Как проверить текущую версию:

• откройте настройки репозитория, организации или предприятия;
• перейдите к списку Actions и self-hosted runners;
• найдите нужную машину по имени и зафиксируйте группу, метки, архитектуру и отображаемую версию;
• на самой машине откройте каталог установленного Runner и выполните штатный скрипт диагностики или проверьте журналы службы;
• сопоставьте результат с текущей инструкцией загрузки в аккаунте и официальным списком выпусков actions/runner.

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

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

Личный разработчик: сохранить единственный Mac Runner и не потерять сборку

Если у вас один Mac-узел сборки, обновление «на месте» выглядит просто, но создаёт скрытый простой. При остановке службы вы одновременно теряете регистрацию, локальные инструменты, кеши и возможность проверить, что новая версия действительно может выполнить проект.

Перед изменением сохраните:

• имя узла, группу и все метки, включая метки архитектуры и назначения;
• рабочие каталоги, настройки репозитория и список переменных окружения;
• состояние службы Runner и пользователя, от имени которого она запускается;
• версии Xcode, SDK, Ruby, Node.js, Python и fastlane, если они участвуют в пайплайне;
• записи о сертификатах, профилях и доступе к связке ключей — без копирования секретов в обычный текстовый файл;
• последний успешный идентификатор сборки и путь к диагностическим журналам.

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

Порядок действий для одной машины:

1. Запишите исходное состояние: версия Runner, статус службы, метки, последний успешный workflow и хеш проекта.
2. Проверьте, что резервный маршрут действительно выбирается правилами runs-on. Не достаточно зарегистрировать машину: она должна иметь нужные метки и доступ к репозиторию.
3. Остановите службу штатным способом, не удаляя каталог рабочего Runner и не очищая кеши до завершения проверки.
4. Запустите обновление по текущей инструкции аккаунта. Если автообновление отключено, используйте официальный пакет или механизм, предложенный интерфейсом; не подставляйте случайный архив из стороннего источника.
5. Запустите службу, проверьте регистрацию и дождитесь актуального статуса версии.
6. Выполните небольшой реальный workflow, затем полноценную сборку приложения с тестами, подписью и архивированием, если узел используется для релиза.
7. Перезагрузите Mac и подтвердите автоматический запуск службы, повторную регистрацию и получение нового задания.

Критерий остановки здесь жёсткий: если после обновления Runner зарегистрирован, но реальный workflow не получает задание, не продолжайте «лечить» production-узел экспериментальными командами. Верните трафик на резервный маршрут и разбирайте журналы отдельно.

Небольшая команда: сначала отделить общий узел от критичного релиза

В небольшой команде риск обычно связан не только с версией Runner. Несколько репозиториев могут использовать один Mac, но предъявлять разные требования к кешу, связке ключей, Xcode и локальным утилитам. Поэтому обновление общей машины без инвентаризации часто ломает именно публикацию, хотя обычные тесты продолжают проходить.

Разделите рабочие процессы на категории:

• проверка pull request и обычные тесты;
• ночные или тяжёлые сборки;
• подпись, архивирование и публикация;
• задачи с фиксированной меткой, определённым Xcode или доступом к секретам.

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

Практическая серая схема:

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

Если новый узел не видит нужную связку ключей, кеш или локальный инструмент, это не ошибка маршрутизации GitHub Actions. Это неполная реконструкция среды. Восстановите зависимость явно или оставьте релиз на старом узле до готовности резервного.

Сравнивайте варианты так:

Этот выбор относится именно к управлению версией, а не к первоначальной установке. Если вам нужен отдельный порядок постоянного запуска службы, используйте руководство по выделенному Mac для CI/CD, но не смешивайте установку с приёмкой обновления.

Фиксированная версия и закрытая сеть: обновление становится процессом

Отключённое автообновление не отменяет требования поддерживать Runner. Оно лишь переносит ответственность на администратора. Узел может оставаться онлайн, принимать локальные команды и при этом оказаться непригодным для новых заданий после начала применения минимальной версии.

Проверьте цепочку обновления по слоям:

• DNS и исходящее соединение до необходимых сервисов;
• прокси и правила TLS-инспекции;
• источник установочного пакета;
• контрольную сумму или другой доступный способ проверки целостности;
• права сервисной учётной записи на каталог Runner и запуск службы;
• место на диске и возможность сохранить журнал;
• дату последней успешной попытки обновления.

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

Для такого узла заведите повторяемую процедуру:

1. получить пакет в контролируемом сегменте;
2. проверить источник и целостность;
3. передать пакет на Mac по утверждённому каналу;
4. остановить службу и сохранить журналы;
5. обновить Runner;
6. проверить запуск от сервисной учётной записи;
7. выполнить тестовое и настоящее задание;
8. записать версию, время, результат и план возврата.

Если обновление прерывается, не удаляйте старую установку до подтверждения нового запуска. Вернуться можно только к состоянию, которое действительно сохранено: каталог, конфигурация службы, метки, права и совместимый набор инструментов должны быть восстановимыми. Резервная копия одного исполняемого файла не является полноценным откатом.

Крупный пул: разделить инвентаризацию, расширение и возврат

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

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

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

Первую партию выбирайте среди неприоритетных узлов. Затем наблюдайте:

• регистрацию и соответствие меток;
• получение заданий;
• ошибки в журналах;
• долю неуспешных workflow относительно базовой линии;
• выполнение тестовой сборки;
• прохождение публикационного маршрута на узлах, которым разрешён релиз.

Сведения о состоянии можно дополнить через REST API self-hosted runners, но API не заменяет реальную сборку. Он помогает получить список и состояние объектов; доказательством готовности остаются логи задания, артефакт и результат перезапуска.

Разворачивайте изменение в три фазы:

• тест: ограниченная группа и заранее выбранный набор workflow;
• расширение: низкорисковые репозитории и затем критичный маршрут;
• откат: заранее определённое условие возврата и сохранённая рабочая конфигурация.

Стоп-условия должны быть измеримыми: Runner не регистрируется, метка потеряна, задания не забираются, подпись не проходит, архив отличается от контрольного или служба не восстанавливается после перезапуска. Формулировка «понаблюдаем ещё немного» не заменяет порог остановки.

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

Приёмка релиза: обычный тест не доказывает готовность Mac

Ответственный за выпуск должен проверять не только зелёный job. Минимальная приёмка состоит из последовательности:

1. Runner виден в нужной группе и имеет исходные метки.
2. Тестовый workflow действительно выполняется на обновлённом узле.
3. Проект собирается с тем же Xcode и SDK, которые указаны в репозитории.
4. Автоматические тесты завершаются успешно.
5. Сертификат и профиль находятся в ожидаемом хранилище, а подпись проходит без ручного вмешательства.
6. Архив создаётся и передаётся следующему этапу.
7. Публикационный workflow проходит на отдельном разрешённом маршруте.
8. После перезагрузки Mac служба запускается, Runner регистрируется и принимает новое задание.

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

Практическое правило выбора после приёмки:

• продолжайте использовать текущий узел, если версия подтверждена, все метки сохранены, реальные сборки и перезапуск прошли;
• перестройте узел, если окружение нельзя воспроизвести или откатить безопасно;
• временно добавьте удалённый Mac, если production-машину нельзя остановить, а резервный маршрут ещё не проверен;
• не возвращайте старый Runner в пул только потому, что он снова показывает «Online».

Если вы рассматриваете изолированный физический Mac как резервный контур, заранее сопоставьте его с различиями выделенного и виртуального macOS-окружения. Для CI важны не только вычислительные ресурсы, но и доступ к Xcode, связке ключей, перезапуску службы и повторяемости окружения.

Что выбрать после проверки: оставить, пересобрать или добавить удалённый Mac

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

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

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