GitHub Actions macOS 14 Runner выведен из эксплуатации: как перенести CI? 2026

macOS 14 Runner: дата вывода и решение для миграции

2 ноября 2026 года GitHub вывел из эксплуатации метки macos-14, macos-14-large и macos-14-xlarge. Если workflow всё ещё назначает одну из них, не заменяйте её автоматически на latest: сначала сопоставьте требования проекта к macOS, Xcode и архитектуре с поддерживаемыми образами, затем проведите изолированный прогон сборки, тестов и выпуска. Дату и список затронутых меток подтверждает официальное объявление GitHub о выводе образа macOS 14.

Кому пригодится: командам Apple-разработки, у которых в workflow остались macos-14, macos-14-large или macos-14-xlarge, и инженерам, отвечающим за подпись, тестирование и публикацию. DevOps- и платформенным специалистам материал поможет задать критерии приёмки нового окружения и заранее определить условия отката.

Последнее обновление: 8 ноября 2026 года. Сведения проверены по объявлению GitHub об окончании поддержки, документации GitHub-hosted runners и репозиторию runner-images.

Сначала установите область воздействия и доступность меток

Сама замена строки runs-on не доказывает, что новая среда подходит проекту. Нужно выяснить, какие задания используют устаревшие метки, как они запускаются и какие требования предъявляют к macOS CI. Информация об образах и доступных метках может меняться, поэтому при выборе сверяйтесь с текущей документацией GitHub и описанием конкретного образа в репозитории runner-images, а не только с текстом объявления об окончании поддержки.

Как найти задания, которые требуют миграции

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

Для каждого затронутого задания зафиксируйте:

• репозиторий, workflow, job и значение runs-on;
• выполняемые команды сборки, тестирования, подписи и публикации;
• версии Xcode и SDK, которые workflow выбирает явно или получает из образа;
• архитектурные требования зависимостей и используемых бинарных инструментов;
• доступ к приватным пакетам, секретам, хранилищам артефактов и внешним сервисам.

Такой перечень снижает риск пропустить редко запускаемый релизный workflow: обычный CI может продолжать работать, а публикация из защищённой ветки — отказать при первом запуске после переключения.

Где искать замену старому Runner

Сначала откройте текущий список GitHub-hosted runners и их меток, затем сверьте нужную платформу с составом образов в runner-images. Метки вроде macos-15 или macos-26 рассматривайте только в том случае, если они доступны для нужного типа Runner в актуальной документации на момент изменения workflow. Не считайте рекомендацию из объявления полным перечнем всех вариантов, доступных вашей организации.

Какую метку выбрать вместо macos-14? Выбирайте не наиболее новое имя само по себе, а образ, который одновременно отвечает требованиям проекта к системе, Xcode и архитектуре. Если подходящей поддерживаемой метки нет, оставьте задание на прежней конфигурации только на время допустимого перехода, если она ещё работает, либо вынесите проверку на другой подходящий исполнитель; не переводите производственный выпуск на непроверенный образ.

Перед изменением основного workflow сохраните исходное значение runs-on и зафиксируйте версию Xcode, SDK и важные переменные окружения из последнего успешного запуска. Без исходного состояния сложно понять, вызвано ли изменение отказом образа, обновлением инструментария или самой правкой workflow.

Затем проверьте совместимость macOS, Xcode и SDK

Метка Runner обозначает среду исполнения, но не обещает совместимость всего проекта. Образ может содержать другую версию macOS, а заданная в workflow версия Xcode может иметь собственные требования к системе. В результате смена образа меняет сразу несколько условий, даже если YAML-файл отличается одной строкой.

Для проверки версий используйте официальные примечания к выпуску Xcode 26 и системные требования Xcode. Сверьте выбранную версию Xcode с установленной системой и нужным SDK. Отдельно отметьте, использует ли проект стабильный выпуск или предварительную версию: наличие Beta в образе не означает, что она подходит для выпускной сборки.

Что проверять при переходе с macos-14 на macos-15 или macos-26? Сначала подтвердите поддержку установленной версии Xcode в выбранной macOS, затем проверьте целевые SDK, сценарии сборки и доступность нужных Simulator-устройств. Название более нового образа не подтверждает, что он содержит нужную связку Xcode и SDK; проверяйте фактическую версию в логе задания и в перечне программного обеспечения образа.

В workflow полезно явно выводить сведения о среде до сборки: версию macOS, выбранный Xcode, версию инструментов командной строки и доступные SDK. Команды sw_vers, xcodebuild -version и xcodebuild -showsdks помогают получить эти сведения непосредственно во время job. Сохраните вывод рядом с логами сборки: тогда при сравнении запусков будет видно, изменилась ли среда так, как ожидалось.

Если проект использует несколько конфигураций Xcode, тестируйте каждую нужную конфигурацию явно, а не полагайтесь на версию по умолчанию. Проверьте, не выбирает ли часть workflow Xcode через xcode-select, переменные окружения или стороннее действие. Иначе один job может собираться ожидаемым инструментарием, а другой — неожиданно использовать системный выбор образа.

Отдельно подтвердите архитектуру и нативные зависимости

Архитектура — самостоятельный критерий миграции. Исполнитель может иметь подходящую версию macOS, но не подходить заданию, которое использует Intel-only инструмент, двоичный пакет с ограниченной поддержкой платформ или скрипт, предполагающий определённое значение архитектуры. Успешный запуск Runner подтверждает лишь то, что job стартовал; он не доказывает совместимость всех нативных компонентов.

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

Как организовать Intel-сборку после вывода macOS 14 Runner? Сначала выясните, действительно ли проекту необходим Intel, или ограничение относится лишь к одному бинарному компоненту. Если требуется Intel-исполнение, выбирайте только Runner, который явно предоставляет нужную архитектуру согласно текущей документации; иначе рассмотрите обновление зависимости или отдельный исполнитель с подтверждённой совместимостью. Не предполагайте, что замена версии macOS автоматически сохраняет ту же архитектуру.

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

Принимайте миграцию по результатам всей цепочки доставки

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

Проверка сборки, Simulator и подписи

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

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

Условия переключения и отката

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

Переходите к рабочему переключению, если выполнены все условия:

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

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

Для задания с матрицей платформ, версий или схем используйте правила матриц workflow GitHub Actions. Матрица помогает явно представить проверяемые сочетания, но не заменяет анализ зависимостей: неподдерживаемый вариант может давать систематически красный job и затруднять диагностику полезных результатов.

Учитывайте кэш, сеть и ответственность за обслуживание

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

В случае приватных пакетов и внутреннего Git-сервера отдельно подтвердите маршруты доступа, сертификаты, DNS и права токенов. Не делайте вывод о сетевой доступности по успешной сборке открытого проекта: закрытая зависимость может загружаться только на определённых исполнителях. На self-hosted среде команда отвечает за обновления, доступность узла, сетевые правила и безопасное хранение секретов; для GitHub-hosted Runner часть инфраструктурного обслуживания находится на стороне GitHub, но проект по-прежнему отвечает за корректность workflow и секретов.

Если время выполнения, ожидание в очереди или доступность Runner важны для релизного графика, сравнивайте фактические логи своих запусков. Объявление о выводе образа не является гарантией производительности или срока ожидания для другой метки.

Сравните варианты среды по требованиям проекта

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

Используйте удалённый Mac как отдельную среду для повторной проверки

Если GitHub-hosted Runner не даёт нужного контроля над средой, альтернативой может быть самостоятельный macOS-исполнитель или отдельный удалённый Mac. Это не означает, что такая конфигурация автоматически совместима с текущей сборкой: сначала нужно получить доступ к требуемой версии macOS и Xcode, установить зависимости и прогнать те же проверки, что и на целевом Runner. Важно сохранить commit, параметры сборки и отчёты, чтобы сравнение имело смысл.

Для команды, которой нужен постоянный доступ к настоящей macOS-среде для разработки и верификации, описание удалённого Mac поможет оценить этот вариант отдельно от GitHub-hosted CI. Перед выбором следует сопоставить требования к непрерывному запуску, сетевой политике и обслуживанию. Условия использования и доступные варианты размещения команда может проверить на странице тарифов RUVCLOUD.

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

Практический итог для миграции такой: сначала подтвердите метку и содержимое образа по актуальным источникам GitHub, затем отдельно проверьте Xcode, архитектуру, зависимости, тесты и доставку. Только после этого переключайте выпуск. Если проекту дополнительно нужна постоянно доступная Mac-среда для повторной проверки, можно сопоставить её требования с вариантами RUVCLOUD; для стабильной тяжёлой нагрузки или обязательного физического оборудования сначала оцените, подходит ли аренда под эксплуатационную модель команды.