Что делать, если устарела версия GitHub Actions self-hosted Mac Runner? Руководство по исправлению 2026

При разборе сбоя не смешивайте регистрацию нового узла с выполнением workflow уже зарегистрированным узлом. Это отдельные проверки. Версия, которая позволила зарегистрировать Runner, со временем может перестать поддерживаться при выполнении заданий. И наоборот, отображение компьютера в списке онлайн подтверждает лишь доступность для связи, но не готовность выполнить конкретную сборку.

Для GitHub Enterprise Cloud минимальная версия регистрации и повторной регистрации с 29 сентября 2026 года — Runner 2.329.0. Этот порог не означает, что 2.329.0 останется бессрочным минимумом для выполнения workflow. Требование к запуску динамическое: актуальный статус нужно проверять отдельно, а не выводить из условия регистрации. Объявление GitHub и документация Runner описывают эти аспекты как разные части обслуживания.

Учитывайте и тип GitHub, используемый организацией. Для GitHub Enterprise Cloud с размещением данных принудительное исполнение началось 31 июля 2026 года; GitHub Enterprise Server не подпадает под это объявление. Даты и правила одного продукта нельзя автоматически переносить на другой. Сначала установите модель развёртывания, затем применяйте к ней соответствующее официальное требование. GitHub уточняет область действия и сроки в объявлении.

До обновления соберите сведения по каждому macOS Runner. Укажите уровень регистрации — репозиторий, организация или предприятие, — версию, состояние, занятость и назначение. Зафиксируйте, какие workflow зависят от узла, кто отвечает за обслуживание и откуда поступают установочные файлы.

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

Может ли устаревший GitHub Actions Runner перестать выполнять задания, если он отображается онлайн? Да. Онлайн-статус показывает, что узел доступен для связи, но не отменяет требований к версии и не подтверждает, что workflow будет назначен и завершится успешно. Для допуска проверяйте установленную версию, текущий статус поддержки и результат пробного задания.

В реестр стоит включить:

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

Такой список помогает различить локальную неисправность и системную причину. Например, если обновлённый компьютер успешно выполняет задачи, но вновь созданная машина возвращается к старой версии, источник проблемы может быть в образе или сценарии регистрации, а не в настройке самого Runner. Для Mac CI Runner это особенно важно, когда разные узлы обслуживают сборку, тестирование, подписание и подготовку релиза в рамках iOS CI/CD.

Чтобы узнать, поддерживается ли конкретная версия, используйте REST API GitHub со сведениями о версиях self-hosted Runner. Запросите статус до планирования работ и сохраните результат вместе с записью об узле. В реестре должны оставаться версия, дата проверки и принятое действие: обновить, наблюдать или вывести Runner из обслуживания.

Не подменяйте проверку правилом «версия не ниже 2.329.0 — значит, всё исправно». GitHub указал этот номер как порог регистрации и повторной регистрации, а не как неизменное требование к выполнению workflow. Для текущей поддержки запуска используйте актуальные данные API; при изменении правил или появления нового срока перепроверьте весь парк.

Как найти дату окончания поддержки конкретной версии? Выполните предусмотренный GitHub запрос к API для своей установки и сопоставьте результат с реестром узлов. Проверяйте отдельно сведения о регистрации и исполнении заданий: статус одного типа нельзя переносить на другой. Сохраните ответ API вместе с датой запроса, чтобы при инциденте было понятно, на какой информации основывалось решение.

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

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

Как обслуживать Runner при отключённом автоматическом обновлении? Назначьте ответственного, который следит за актуальным статусом версии, планирует ручную установку и сохраняет результаты проверки. Отключённое автообновление само по себе не делает узел непригодным, но без регламента версия может остаться без контроля, а восстановленный компьютер — вернуться с прежним пакетом.

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

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

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

Рекомендуемый ход работ:

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

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

Не возвращайте узел в производственный пул только потому, что установка завершилась без сообщения об ошибке. Если задача не стартовала, разберите назначение Runner, регистрацию, доступ к обновлению и конфигурацию workflow; до успешного теста считайте узел непроверенным.

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

Разовое обновление решает текущую проблему, но не гарантирует, что версия останется поддерживаемой. Включите регулярную сверку через API в операционный регламент и храните её результат в реестре узлов. Частоту определяйте с учётом критичности CI и темпа изменений; при новом официальном сроке или изменении правил проводите внеплановую проверку.

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

Означает ли версия 2.329.0 одинаковое требование для регистрации и запуска workflow? Нет. Это указанный GitHub порог регистрации и повторной регистрации; требование к выполнению заданий зависит от текущего статуса поддержки. Поэтому эксплуатационный контроль должен учитывать обе проверки отдельно, а допуск к работе подтверждаться реальным запуском задачи.

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

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

Если во время модернизации нужно временно добавить macOS-мощность или сохранить резерв для тестирования, удалённая аренда Mac может быть вариантом для оценки, но не заменяет исправление Runner и приёмку CI. Сначала сопоставьте условия доступа и расходы с требованиями команды: тарифы NUKCLOUD и условия обслуживания. Для перехода на удалённую среду отдельно изучите справочные материалы по подключению. Допускайте такой узел к iOS CI/CD только после проверки версии Runner, инструментов и полного целевого workflow.