Перенесите рабочие процессы с macOS 14 Runner до его вывода из эксплуатации: сначала проверьте новый образ параллельно с действующим, а затем переключайте задания только после успешной сборки, тестов и проверки публикации. Это особенно важно, если CI подписывает приложения или выпускает артефакты, которые нельзя считать проверенными по одному лишь статусу «сборка завершена».
Материал пригодится разработчикам, которые пока используют метки macOS 14 и проверяют совместимость проекта с новым окружением.
Инженерам CI — чтобы сравнить зависимости, кэш, тесты и результаты сборки без необоснованных изменений в производственном процессе.
Ответственным за платформу — чтобы определить, достаточно ли управляемого Runner или проекту нужна отдельная удалённая среда Mac.
Последнее обновление: 7 октября 2026 года. Сведения о сроке, затронутых метках и порядке вывода сверены с официальным объявлением GitHub о прекращении поддержки образа macOS 14. Перед переключением проверьте, не изменились ли объявление, доступные образы или расписание brownout.
Этап обнаружения: определите, какие задания затронет вывод образа
GitHub сообщил, что образ macOS 14 для размещённых Runner планируется вывести из эксплуатации 2 ноября 2026 года. В объявлении перечислены метки macos-14, macos-14-large и macos-14-xlarge; там же приведены сведения о brownout в переходный период и рекомендованные варианты миграции. Срок и состав меток привязаны к объявлению GitHub от 1 октября 2026 года, поэтому перед публикацией изменений их следует перепроверить в первоисточнике.
Когда перестанет поддерживаться macOS 14 Runner в GitHub Actions? Согласно текущему объявлению, плановая дата вывода образа — 2 ноября 2026 года. Не следует воспринимать brownout как удобное окно для начала миграции: временная недоступность старого образа может проявиться уже в период подготовки. Проверяйте точное расписание и условия в официальном уведомлении, а не переносите дату из чужой инструкции без повторной сверки.
Начните с поиска не только явных упоминаний macos-14, но и параметров, которые косвенно связывают задание с прежним окружением:
- в файлах рабочих процессов проверьте
runs-on, матрицы сборки, переиспользуемые workflow и условияif; - найдите обращения к собственным composite actions и скриптам, если они передают метку Runner через входные параметры;
- сопоставьте найденные задания с ветками, тегами и событиями, которые их запускают;
- отметьте, какие задания собирают приложение, какие выполняют тесты, а какие подписывают или публикуют артефакты;
- назначьте ответственного за решение по каждому затронутому workflow, чтобы переход не остался только задачей команды CI.
Сверяйте метку Runner с тем, что именно она означает: это выбор размещённой среды, а не обещание конкретной версии Xcode или набора установленных инструментов. Состав программного обеспечения в образах меняется. Для этой проверки используйте официальный репозиторий образов Runner, а сроки, brownout и рекомендуемые метки — в объявлении о выводе macOS 14.
Важно: не заменяйте все упоминания старой метки массовым поиском и заменой, пока не выяснили, какие задания требуют отдельной архитектуры, установленного инструмента или особого порядка публикации.
Этап подготовки: зафиксируйте исходное состояние проекта
До испытания нового образа сохраните параметры, которые нужны для честного сравнения. Иначе изменение версии инструмента, способа установки зависимости и самого исходного кода окажется в одном наборе изменений, и причина сбоя станет неясной.
Зафиксируйте используемую версию Xcode и SDK, целевую платформу проекта, команду сборки, параметры тестирования и способ получения зависимостей. Отдельно запишите, какие части окружения задаются в YAML рабочего процесса, а какие получаются из образа Runner. Версия macOS на образе, архитектура, версия Xcode, deployment target проекта и настройки workflow — разные сущности; совпадение одной из них не подтверждает совместимость остальных.
Сохраните последний типичный журнал сборки, результат тестов и критерии проверки артефакта. Для приложения, которое проходит архивирование и подписание, критерии должны отражать всю цепочку: от сборки до проверки того, что полученный файл и сведения о подписи соответствуют требованиям проекта. Успешный xcodebuild build сам по себе не доказывает, что архив можно передать в последующий этап выпуска.
Проверьте также, что именно восстанавливает кэш. Кэш зависимостей не заменяет установленные в системе инструменты и может скрыть различия между образами, если ключ не учитывает значимые параметры. Сопоставьте ключи и область хранения с документацией GitHub по кэшированию зависимостей. Не очищайте все кэши заранее: сначала выясните, какая запись может влиять на результат, и меняйте только то, что можно проверить.
Практический исходный чек-лист:
- [ ] Сохранены текущие
runs-on, параметры Xcode и способ установки зависимостей. - [ ] Записаны запускаемые тесты и критерии их результата.
- [ ] Определены шаги архивирования, подписи и последующей передачи артефакта.
- [ ] Проверены ключи кэша и скрипты, зависящие от названий каталогов или инструментов.
- [ ] Для каждого критичного задания указан ответственный и определён приемлемый результат проверки.
Этап испытания: запустите новый Runner отдельно от производства
На первом испытании не заменяйте метку во всех рабочих процессах. Создайте отдельную ветку или параллельное задание, которое повторяет существенные команды действующего workflow, но запускается на рекомендуемом образе. Синтаксис runs-on, матриц и условий проверьте по справочнику GitHub по синтаксису workflow.
Кандидатами могут быть поддерживаемые метки macOS, предложенные в уведомлении GitHub. Выбор между macos-15 и macos-26 нельзя делать только по номеру версии: сопоставьте их с требованиями проекта и текущими списками установленного программного обеспечения. GitHub публикует отдельные перечни для образа macOS 15 и образа macOS 26; состав и версии инструментов следует проверять непосредственно перед испытанием.
| Вариант Runner | Что проверить до выбора | Когда разумно начать с него |
|---|---|---|
macos-15 |
Наличие нужного Xcode и системных инструментов в актуальном списке образа; совместимость библиотек и скриптов | Если проекту нужен более осторожный переход и его зависимости проверены на этом образе |
macos-26 |
Наличие необходимой цепочки разработки; отсутствие привязок к прежнему поведению ОС и инструментов | Если проектная матрица и используемые зависимости допускают работу на более новом образе |
| Другая метка из объявления GitHub | Поддерживается ли она сейчас и соответствует ли назначению задания | Если это прямо рекомендованный вариант для конкретного сценария |
Таблица не заменяет проверку реального образа: метка обозначает класс среды, но доступные версии программ следует подтверждать по официальному перечню и журналу конкретного запуска. Сверьте также архитектуру и параметры задания. Не выводите их из имени метки без проверки сведений в документации GitHub о размещённых Runner.
Во время параллельного запуска сравнивайте не только итоговый код завершения. Проверьте, совпадают ли ожидаемые тестовые наборы, создаются ли необходимые файлы и не изменился ли способ выбора Xcode. Если workflow включает публикацию, на этапе испытания безопаснее ограничить или отключить её: проверка кандидата должна подтверждать выпускной путь, но не создавать случайную производственную публикацию.
Совет: если тест провалился, сохраните полный журнал и окружение запуска до исправления. Повтор после нескольких одновременных правок часто показывает лишь то, что набор изменений помог, но не объясняет первопричину.
Как проверить перенос workflow до вывода macOS 14 Runner? Запустите копию затронутого задания на отдельной ветке или параллельном Job, сравните настройки и журналы, затем выполните реальные тесты и этапы подготовки артефакта. Переключение не считается проверенным, пока проект не прошёл критичные шаги на выбранной метке и команда не понимает, почему результаты могут отличаться.
Этап исправлений: отделите проблему образа от предположений в скриптах
Если новый запуск завершается ошибкой, сначала определите её этап: подготовка среды, установка зависимостей, компиляция, тесты или обработка артефакта. Сравните журнал кандидата с базовым журналом, а затем проверьте конкретное различие — системный инструмент, версию SDK, разрешение зависимостей, архитектурную ветку или работу кэша. Один общий шаг «обновить всё» затрудняет диагностику и может создать новые несовместимости.
Отдельно ищите исторические допущения о macOS 14: жёстко заданный путь к инструменту, проверку версии ОС в скрипте, неявное использование предустановленной утилиты или условие, которое выбирает зависимость по архитектуре. Если требование не связано с задачей проекта, устраните привязку; если связано — задокументируйте её и проверьте, какие поддерживаемые метки удовлетворяют условию.
Для матриц сборки просмотрите каждую комбинацию, которая действительно нужна продукту. Успешная проверка одного варианта Xcode не доказывает работу остальных заданий. При этом не расширяйте матрицу без необходимости: сначала подтвердите набор поддерживаемых конфигураций проекта и отделите обязательные проверки от временных диагностических запусков.
| Наблюдение в журнале | Что проверять сначала | Как действовать |
|---|---|---|
| Не найден инструмент или каталог | Список программ образа и предположения в скриптах о путях | Сопоставить образ с официальным перечнем, затем исправить путь или явно устанавливать необходимый инструмент |
| Изменился результат разрешения зависимостей | Файл фиксации версий, источник зависимости и команды установки | Повторить установку с зафиксированными входными данными и менять способ разрешения только при подтверждённой причине |
| Ошибка возникает только при восстановленном кэше | Ключ кэша, его входные параметры и содержимое восстановленной записи | Испытать адресное изменение ключа или выборочное отключение кэша, не удаляя всё хранилище заранее |
| Сборка проходит, но тесты отличаются | Состав тестов, системные требования и условия запуска | Убедиться, что кандидат исполнил тот же целевой набор и что различие воспроизводится |
| Архив готов, но выпуск не проходит | Подписание, доступ к секретам, формат и проверка артефакта | Отдельно проверить выпускной этап по правилам проекта, не приравнивая его к успешной компиляции |
Если обновление зависимости действительно необходимо, фиксируйте его как отдельное изменение и проверяйте независимо от переключения Runner. Так легче откатить именно изменение окружения, не возвращая случайно исправления проекта. Для диагностики используйте минимальное изменение, которое подтверждает гипотезу; полная очистка кэшей и широкое обновление инструментов не должны быть рутинной первой реакцией.
Что проверить после перехода с macOS 14 на macOS 15 или macOS 26? Сопоставьте доступные версии Xcode и системных инструментов по актуальным перечням образов, архитектуру Runner, команды установки зависимостей, кэш, тесты и обработку результата сборки. Отдельно убедитесь, что deployment target задаётся проектом, а не ошибочно выводится из версии macOS на Runner.
Этап приёмки: подтвердите не только сборку, но и выпускной путь
Кандидат можно считать готовым не тогда, когда компилятор завершил работу, а когда на нём прошли проверки, от которых зависит реальный релиз. Для каждого критичного workflow проверьте целевую сборку, тесты, архивирование, подпись и дальнейшую обработку артефакта в том объёме, который предусмотрен вашим процессом. Если публикация требует отдельного разрешения, проверяйте её контролируемым способом и фиксируйте результат отдельно.
Не смешивайте разные виды приёмки:
- Сборка подтверждает, что заданная конфигурация создаёт ожидаемый продукт.
- Тесты подтверждают, что запланированные проверки выполняются и дают приемлемый результат.
- Подписание и архивирование подтверждают, что цепочка подготовки релизного артефакта не сломана.
- Публикация подтверждает работу заключительных шагов выпуска, но должна проверяться с учётом риска для реальных пользователей.
Оформите результат проверки так, чтобы следующий ответственный мог повторить её: укажите выбранную метку, существенные параметры запуска, тестовый набор, ссылки на журналы и состояние каждого этапа. Не приписывайте миграции успешность на основании запуска, который пропустил тесты или был остановлен до архивирования.
Управляемый Runner и удалённый Mac решают не одну и ту же задачу. Первый удобен для workflow, который можно описать в GitHub Actions и запустить на доступном стандартном образе. Если проекту требуется постоянное состояние узла, более детальный контроль над окружением или продолжительная работа вне обычного цикла задания, стоит отдельно оценить удалённый Mac. Однако потребность в подключении физического устройства, графической сессии или конкретном оборудовании требует отдельной проверки: удалённая машина не должна автоматически считаться заменой каждому локальному тесту.
| Критерий | Размещённый GitHub Actions Runner | Удалённый Mac |
|---|---|---|
| Управление средой | Выбор поддерживаемой метки и конфигурация в workflow; состав образа нужно отслеживать | Может подойти, если проекту необходим более непосредственный контроль над хостом; доступные возможности зависят от конкретного предложения |
| Жизненный цикл заданий | Подходит для автоматизированных запусков в CI | Может рассматриваться для длительных процессов или узла, состояние которого важно сохранять |
| Обслуживание | Важны изменения образов и обновления списков программ | Ответственность за состояние, обновления, доступ и обслуживание следует определить заранее |
| Подходящий критерий выбора | Проект помещается в поддерживаемую среду и проходит проверки на ней | Есть подтверждённое требование к постоянной или более контролируемой среде, которого не хватает Runner |
Когда размещённого macOS Runner недостаточно и имеет смысл оценивать удалённый Mac? Когда проверка показывает не просто разовое несовпадение библиотек, а устойчивое требование к контролю хоста, сохранению окружения или непрерывному выполнению задач. Если же проблему можно устранить переносимой конфигурацией workflow и подтверждёнными настройками образа, переход на отдельный Mac может добавить обслуживание без доказанной пользы.
Этап переключения: включайте новый образ после решения ответственных
Перед производственным переходом зафиксируйте, какой результат считается достаточным и кто принимает решение. Условием переключения должны быть успешная сборка, нужный набор тестов и приёмка тех шагов подписи и выпуска, которые применимы к проекту. Для заданий, где публикация отключена в параллельном испытании, запланируйте контролируемую проверку соответствующего этапа отдельно.
Дальше меняйте производственные workflow небольшими группами. После каждого изменения проверьте, что запуск действительно использует нужную метку, не запускает старый путь через переиспользуемый workflow и сохраняет предусмотренные ограничения на публикацию. Удаляйте ссылки на macOS 14 после того, как подтверждено, что они больше не нужны; сохраните историю изменений и журналы, которые объясняют принятое решение.
Заранее определите условия остановки: например, не проходит обязательный тест, исчезает требуемый инструмент, не формируется проверяемый архив или не работает критичная часть подписи. При таком результате остановите дальнейшее распространение изменения и вернитесь к последней проверенной конфигурации, если старый Runner ещё доступен и это допустимо по официальному графику. После вывода образа из эксплуатации рассчитывать на прежнюю метку как на надёжный способ отката нельзя — альтернативу нужно определить заранее.
Итоговая проверка перед изменением производственной конфигурации:
- [ ] Указана рекомендуемая метка, а её актуальный образ и состав инструментов проверены по официальному списку.
- [ ] Базовый запуск сопоставлен с кандидатом по командам, параметрам и тестовым целям.
- [ ] Критичные тесты и выпускные действия проверены отдельно и имеют зафиксированный результат.
- [ ] Назначен ответственный за переключение и согласованы условия остановки или отката.
- [ ] Удаление старой метки запланировано только для заданий, где зависимость от неё действительно устранена.
Если переход затрагивает постоянную среду, которую трудно воспроизвести в стандартном Runner, сравните стоимость обслуживания обоих вариантов не только по времени запуска. Учитывайте время на обновление инструментов, диагностику, контроль доступа и восстановление после изменений. Данные о конкретных тарифах и возможностях удалённой машины нужно брать из актуальных условий сервиса, а не выводить из описания GitHub Runner. Перед оценкой можно сверить опубликованные тарифы RUVCLOUD и доступные условия оформления удалённого Mac.
В итоге управляемый Runner остаётся рациональным выбором, если новая поддерживаемая метка проходит проектные проверки, а команде не требуется сохранять собственное состояние хоста. У него есть реальные ограничения: набор образов меняется, переход между версиями требует повторной проверки, а детали окружения нельзя считать неизменными только потому, что YAML workflow не менялся. Если эти условия мешают выпуску и необходимы фиксируемая среда, непрерывно доступный узел или более непосредственный контроль системы, аренда удалённого Mac может оказаться удобнее — после проверки конкретных условий и ответственности за обслуживание. Для разовых сборок без такой потребности отдельный Mac может быть избыточен; для устойчивой нагрузки стоит сопоставить аренду с покупкой собственной машины и затратами на её поддержку.
Перенос GitHub Actions macOS 14 Runner завершён только тогда, когда на новом окружении подтверждён реальный путь проекта — от сборки и тестов до необходимых действий с артефактом. Если после миграции стандартного Runner недостаточно, изучите сценарий удалённого Mac CI и границы его применения, а затем принимайте решение по фактическим требованиям к контролю среды, длительности работы и поддержке.