GitHub Actions macOS runner | эластичный пул или постоянные узлы (2026)

Когда iOS и macOS команды живут в коротких релизных циклах, CI редко бывает ровной линией: в одни часы накладываются десятки workflow. Минуты GitHub-hosted macOS заканчиваются быстро, и организации добавляют self-hosted runner на железе Apple. Следующий развилка важнее маркетинга: эластичный пул облачных Mac, который масштабируется вверх-вниз, или постоянные узлы, которые всегда тёплые. Ответ держится на форме очереди, допустимой задержке и том, где живут кэши — а не на лозунгах вендоров.

p95

Бюджет очереди и холодного старта

Duty

% занятости в часы пик vs простой

Кэш

Целевой hit rate на main

Сначала смоделируйте пик — потом покупайте ёмкость

Эластичный пул выигрывает, когда средняя утилизация низкая, но пики конкурентности высокие: несколько дней в месяц нужно шесть runner'ов, а остальное время хватит двух. Постоянные узлы выигрывают, когда работа приходит непрерывно — ночные сборки, матрица на каждый PR и боты, которые не должны ждать провижининга. Возьмите семь дней логов Actions: медианная глубина очереди, p95 от queued до in_progress и как часто два job'а спорят за подпись на одном хосте. Если p95 очереди уже выше допустимого «простоя разработчика», масштабирование помогает только если новые машины готовы быстрее, чем растёт хвост — иначе вы платите за холодные старты поверх очереди.

Для недели App Store и финансовой рамки «купить vs арендовать» у нас отдельная матрица — её можно использовать как чеклист: Внезапные сборки и срочная проверка App Store в 2026: купить Mac или арендовать облачный Mac посуточно или на неделю?

Задержка — это три числа, а не один слоган

Разделите задержку control-plane (runner забрал job), data-plane (git fetch, восстановление кэша, upload артефактов) и инструментальную (компиляция Xcode). Эластичный пул часто снимает contention на control-plane за счёт labels, но если каждая свежая VM снова тратит пять минут на bootstrap зависимостей, wall time почти не двигается. Постоянные runner'ы амортизируют bootstrap сотнями job'ов — ценой простоя по питанию и риском дрейфа образа без пинов.

Важен сетевой путь: измерьте RTT и пропускную способность до Git-хоста и до удалённого кэша (S3-совместимый, Artifactory или Actions cache). Медленное TLS к далёкому региону на скриншотах выглядит как «тормозит Xcode». Для headless-паттернов и launchd см. Развёртывание OpenClaw на облачном Mac в 2026: проверки macOS вместо Linux VPS, launchd и воспроизводимый FAQ.

Определения

«Эластичность» здесь — это ёмкость, которую можно добавить за минуты и убрать при простое, а не волшебный выключатель очередей. Если провайдер не выдаёт ещё один Mac до конца всплеска, всё равно нужен always-on baseline.

Кэши: липкий диск vs общий object store

Сборки Apple чувствительны к кэшу: DerivedData, CocoaPods и артефакты SwiftPM задают время restore. Эластичные узлы, которые выбрасывают диск при выключении, должны выносить кэш наружу — версионированные бакеты или read-heavy сеть — с ключами, привязанными к минорной версии Xcode и хэшам lockfile. Постоянные узлы держат горячий кэш локально, но нужно детерминированно вытеснять, чтобы ветка A не отравила ветку B. В обеих моделях промахи кэша закладывайте в SLO, а не считайте редкой случайностью.

Подпись и изоляция

Self-hosted runner'ы под одним пользователем умножают гонки Keychain и provisioning profile. Предпочтительнее одна идентичность runner на машину или эфемерные пользователи, если оркестратор позволяет; не параллельте релизную подпись в общем home без гарантий изоляции.

Матрица решений одним взглядом

Таблица — первый фильтр; затем проверьте чеклист параметров ниже. Если в организации уже есть политика по runner groups и labels, зафиксируйте, какие workflow идут на общий пул, а какие — на изолированные машины с отдельным Keychain: это влияет и на стоимость, и на безопасность артефактов. Для команд, которые только переходят с GitHub-hosted, полезно две недели подряд собирать одни и те же метрики в одинаковые интервалы суток — иначе легко спутать сезонный маркетинговый пик с «вечной» потребностью в always-on.

Сигнал	Склоняет к эластичному пулу	Склоняет к постоянным узлам
Коэффициент загрузки	Низкая средняя утилизация, редкие высокие пики	Высокая устойчивая загрузка по часовым поясам
SLO очереди	Пики терпимы, если машины появляются быстро	Жёсткая задержка pickup (<30 с) большую часть дня
Стратегия кэша	Удалённый кэш с хорошим hit rate на холодных runner'ах	Большой локальный SSD, предсказуемые тёплые пути
Комплаенс	Эфемерные диски удовлетворяют политике хранения	Долгий аудит-трейл на фиксированных хостах

Исполняемый чеклист параметров (в runbook)

Это ручки, которые мы реально фиксируем в YAML, переменных Terraform или внутренней wiki при расчёте парка. Имена подстройте под свой слой оркестрации — важен смысл.

Workflow и размер парка (эталон)

# Параллелизм workflow (сериализовать шумные пути)
concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

# Потолок fan-out матрицы (не давить кэш)
strategy:
  max-parallel: 4

# Парк runner (документируйте в ops-репо, не только в UI)
baseline_always_on_runners: 2   # минимальная тёплая ёмкость
burst_elastic_runners_max: 8    # потолок у провайдера
idle_shutdown_minutes: 45       # только elastic; избегать дребезга

# Ключи кэша (обязательно toolchain + lockfiles)
cache_key_prefix: xcode-16_2-spm-${{ hashFiles('**/Package.resolved') }}

# Цели SLO (алерт при превышении)
queue_pickup_p95_seconds: 60
cache_restore_p95_seconds: 120

Гибрид, который переживает реальные оргструктуры

Держите небольшой always-on слой для default branch и release-тегов, а экспериментальные workflow направляйте на elastic labels. Следите за hit rate кэша на elastic runner'ах отдельно — если он рушится, вы лишь переносите время из очереди в restore.

Раз в неделю сравнивайте оплаченные часы runner'ов с throughput слитых PR: если счёт растёт без ускорения поставки, сначала ужесточайте concurrency и ключи кэша, а не добавляйте железо.

Минимальный набор телеметрии на первые 14 дней

Логируйте отдельно время на этапах checkout, cache restore, компиляции и загрузки артефактов; сохраняйте label runner'а и версию образа в каждом job summary. Если p95 restore растёт быстрее, чем растёт длина очереди, проблема не в количестве машин, а в ключах кэша или в удалённом регионе бакета. Добавьте в дашборд долю job'ов, завершившихся по таймауту на этапе зависимостей: так вы отделите сетевые инциденты от нехватки CPU и не будете покупать «ещё один Mac», когда нужен DNS или зеркало репозитория.