Перед выводом из эксплуатации GitHub Actions macOS 14 Runner: как найти все оставшиеся workflow? Чек-лист 2026

Если вы находите старые метки только поиском по YAML в основной ветке, полноту проверки доказать нельзя. Сначала составьте реестр репозиториев, переиспользуемых workflow, динамических конфигураций и фактических запусков, а затем подтвердите миграцию на реальных задачах: GitHub объявил вывод macOS 14 Runner из эксплуатации 2 ноября 2026 года (официальное объявление).

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

Последнее обновление: 8 октября 2026 года. Дата завершения поддержки, затрагиваемые метки и график временных brownout сверены с объявлением GitHub. При изменении объявления повторно проверьте список меток и рекомендуемые замены до принятия решения о миграции.

Какие метрики показывают, что инвентаризация охватила всю организацию?

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

Для оценки используйте отдельные показатели:

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

Границы аудита зафиксируйте до начала поиска: организация, репозитории, обслуживаемые ветви, общие шаблоны и область публикации. Не включайте репозиторий в результат как «чистый», если его содержимое не удалось получить. Отдельно обозначайте архивные, недоступные и исключённые проекты; у каждого исключения должна быть причина и владелец решения.

Когда заканчивается поддержка? В объявлении GitHub указано, что macOS 14 Runner выводится из эксплуатации 2 ноября 2026 года; там же приведены затрагиваемые метки и сведения о временных brownout (объявление о завершении поддержки). Это статус объявленных GitHub hosted runners, а не доказательство того, что отдельный самостоятельно размещённый Mac автоматически перестанет работать в тот же день.

Сначала зафиксируйте исходную область и снимок найденных зависимостей. Тогда изменения в составе организации или настройке общих workflow не будут незаметно менять смысл отчёта.

Источники старых macOS-меток и способы их обнаружения

Перечень macOS-14 runner labels для проверки включает macos-14, macos-14-large и macos-14-xlarge, названные в объявлении GitHub. Ищите не только точное написание метки, но и место, где оно формируется: например, матрица или выражение могут выбирать значение во время выполнения.

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

Проверьте как минимум следующие места:

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

Для переиспользуемых workflow отдельно сопоставьте вызывающую и вызываемую стороны: GitHub описывает передачу настроек и повторное использование в документации по переиспользуемым workflow. Исправление только вызывающего файла не обязательно устраняет старую метку, если фактический runs-on находится внутри общего шаблона. Обратная ошибка тоже возможна: шаблон исправлен, но отдельный вызов передаёт старое значение через входной параметр.

Статический поиск удобен для первого прохода, но не устанавливает полноту. Например, rg -n 'macos-14' .github обнаружит явные вхождения в проверенных файлах, но не докажет, что охвачены все репозитории, ветви, закрытые для сканера проекты или строки, формируемые во время выполнения. Сохраняйте дату сбора, перечень репозиториев и результат доступа, а не только вывод поиска.

Как проверить переиспользуемые workflow? Проследите цепочку от вызывающей задачи до файла общего workflow, проверьте входные параметры и место вычисления runs-on. Если значение задаётся выражением, просмотрите доступные контексты и синтаксис выражений GitHub Actions, а затем подтвердите выбранное значение фактическим запуском. По одному имени файла вызывающей стороны такую зависимость не всегда можно исключить.

Сопоставление конфигурации с фактическими запусками

Статическая конфигурация отвечает на вопрос «где может находиться зависимость», а история запусков — «какая задача действительно использовала этот путь». Для каждой обнаруженной или потенциальной зависимости зафиксируйте репозиторий, workflow, событие запуска, ветвь, источник метки и последний доступный результат.

Используйте данные запусков workflow в интерфейсе GitHub или через REST API запусков workflow. При автоматизации выгрузки обрабатывайте страницы результатов до конца: частичная выдача API не является полным журналом. Сверяйте идентификатор и имя workflow с реестром конфигураций, чтобы не приписать запуск одноимённому файлу из другого репозитория.

Ищите «слепые зоны» по триггерам и жизненному циклу задачи:

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

Отсутствие недавних сбоев — не свидетельство отсутствия зависимости. Задача могла не запускаться, запускаться в отдельной ветке или не достигать условия, выбирающего старый Runner. Записывайте «нет доступного подтверждения» как состояние проверки, а не как результат «миграция не требуется».

Оценка риска для сборки и выпуска

Одинаковая техническая находка может иметь разный бизнес-эффект. Старый Runner в необязательной проверке pull request и старая метка в единственном процессе архивирования и подписи приложения — не равнозначные риски. Свяжите каждый пункт реестра с критичностью задачи, ответственным владельцем и способом безопасного тестирования.

Разделите работу по назначению:

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

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

Временные brownout из объявления полезны как повод проверить готовность заранее, но время такого прогона не заменяет критерии приёмки. Если задача не прошла важный этап — например, тестирование подписи или публикации, — не снимайте блокировку лишь потому, что базовая сборка завершилась успешно.

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

Закрытие миграции проверяемым результатом

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

Как подтвердить охват всех репозиториев? Сверьте полученный перечень с административным списком организации, отметьте недоступные и исключённые проекты и сохраните основание для каждой отметки. Затем сравните реестр файлов и вызываемых workflow с журналами фактических запусков: расхождение означает, что нужно выяснить, какой источник конфигурации или путь выполнения не учтён.

Используйте этот чек-лист как выходной критерий аудита:

• [ ] Зафиксированы организация, репозитории и правила включения в область проверки.
• [ ] Для каждого проекта отмечено состояние доступа: проверен, недоступен или исключён с обоснованием.
• [ ] Проверены прямые вхождения всех трёх затрагиваемых меток: macos-14, macos-14-large, macos-14-xlarge.
• [ ] Прослежены вызываемые и вызывающие reusable workflow, входные параметры и значения runs-on.
• [ ] Проверены матрицы, контексты, выражения и конфигурация, формируемая генераторами или скриптами.
• [ ] Находки сопоставлены с запусками по workflow, ветвям и событиям; непроверенные пути отмечены явно.
• [ ] Каждому затронутому процессу присвоены критичность, ответственный и план проверки.
• [ ] Для выбранной замены записаны конфигурационное отличие, результат реальной сборки и проверка требуемых тестов и публикационных шагов.
• [ ] Неудачные или неполные проверки не закрыты формулировкой «не воспроизводится» без доказательств.
• [ ] Все исключения имеют одобрение, владельца и условие пересмотра.

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

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

Решение по незакрытым зависимостям

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

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

При выборе среды сравнивайте не только вычислительную задачу, но и операционные ограничения. Hosted Runner зависит от набора предложенных меток и изменения образа; собственная Mac-среда добавляет ответственность за обновления, контроль доступа, обслуживание и безопасную работу с секретами. Аренда удалённого Mac сама по себе не гарантирует совместимость с GitHub Actions: отдельно проверьте регистрацию и эксплуатацию self-hosted Runner, сетевые требования, изоляцию задач и правила очистки окружения.

Если вашим проверенным задачам нужен отдельный Mac, а покупать и обслуживать собственные машины сейчас нецелесообразно, сравните этот путь с арендой удалённого Mac у KVMFLUX. Такой вариант не устраняет необходимость самостоятельно спроектировать безопасное подключение CI и проверку процессов, но позволяет оценить использование реального Mac с доступом через VNC, SSH или веб-консоль и root-правами. Сначала сопоставьте сценарий с вариантами применения удалённого Mac, затем сверьте доступные циклы аренды и условия на странице тарифов. Для редкой, уже протестированной задачи временная среда может быть уместна; для постоянно работающей критической инфраструктуры сначала сравните аренду с самостоятельным владением, требованиями изоляции и планом эксплуатации.

Читайте также

• Как масштабировать пул macOS Runner в GitHub Actions и подготовить его к росту нагрузки
• Настройка собственного macOS Runner: регистрация, маршрутизация заданий и эксплуатация
• Выбор между Xcode Cloud и собственным Mac CI после инвентаризации устаревающих Runner