2026: GitHub macOS runner vs выделенный пул сборки в Mac-облаке — параллелизм, поминутная оплата и кэш
Команды спрашивают: хватит ли поминутных macOS runner от GitHub или нужен выделенный пул в Mac-облаке с self-hosted? Текст про CI на стороне Git (не Xcode Cloud), связывает биллинг, очереди и свободное место, даёт таблицу, пять шагов, жёсткие метрики и FAQ.
Основное
1. Кратко
Хостинговые macOS runner оптимизируют поминутную оплату без админки; выделенный пул Mac-облака даёт предсказуемые диски, тулчейны и egress через метки self-hosted. Оба решают задачу Git CI, а не публикации в App Store через Xcode Cloud. Рост max-parallel не гарантирует скорость: у хостинга — очереди организации и тариф за минуты; у self-hosted — конкуренция DerivedData, связка ключей и скачки диска. Смотрите цену минуты, долю ожидания в p95, кэш и свободное место вместе.
Привычки Linux/VPS: одновременные Archive на одной связке ключей, Spotlight, микродрейф Xcode. Хостинг даёт свежий образ каждый job; self-hosted показывает воспроизводимость и нагрузку. Учитывайте время инженеров: дешёвые минуты не спасут, если в релизную неделю очереди раздувают счёт, а фиксированный узел Mac-облака стабилизирует p95.
2. Болевые точки
- Биллинг: минуты растут при пиках нескольких репозиториев; Mac-облако чаще почасово/помесячно плюс трафик.
- Очередь и параллелизм: планировщик GitHub против лимитов CPU/RAM/IO при параллельных
xcodebuild. - DerivedData: эфемерная ФС vs постоянные тома; нужны раздельные пути и уборка.
- Безопасность: корпоративный PKCS, фиксированный выход, демоны — проще на выделенном пуле.
Пятый аспект — наблюдаемость: без мониторинга диска/CPU/launchd на self-hosted команды говорят на разных языках с дашбордами GitHub. Стандартизируйте метки ci-pr / ci-release.
3. Матрица
| Измерение | Хостинг macOS | Выделенный пул Mac-облака |
|---|---|---|
| Оплата | Поминутно | Аренда + трафик |
| Параллелизм | Квоты организации | Свои метки |
| Диск | Кэш API | Постоянные пути |
| Тулчейн | Ритм платформы | Несколько Xcode |
| Подпись | Секреты GitHub | match / API keys под PKI |
self-hosted. Фиксируйте ветки и concurrency в README.4. Пять шагов
- Измерить p50/p95, ожидание очереди, эффективный $/минуту.
- Базовая линия SSH:
xcodebuild -version, ≥40 ГБ свободно, прокси/DNS, RTT до Git. - Разделить DerivedData по меткам; разная ретенция для nightly и PR.
concurrencyдля релизов; поднимать параллелизм после наблюдения пиков RAM.- Горизонтально добавлять узлы при нарушении SLA, дисковых алертах или втором регионе — копировать метки, а не только крутить concurrency.
5. Метрики
- Диск: DerivedData быстро занимает десятки ГБ; ниже ~10 ГБ свободных ссылка становится нестабильной.
- RAM: одиночный Archive на Apple Silicon часто 12–18 ГБ пика — оценка параллелизма.
- RTT: разделяйте ожидание очереди и компиляцию.
- Минуты хостинга: всплеск из-за очереди или медленной сборки — разные фиксы.
- Классификация сбоев: подпись, зависимости, OOM, загрузка.
- ROI кэша: ускорение на фиксированном пути DerivedData.
- Бюджет параллелизма орг: пики нескольких реп умножают очереди.
- Артефакты: крупные
.xcarchiveедят минуты и канал.
Для финансов: CSV GitHub напротив отчётов self-hosted — минуты должны коррелировать со скоростью коммитов, аренда с базовой нагрузкой. Коммиты ровные, минуты растут — ищите кэш или очередь.
6. Узлы вместо слепого параллелизма
Только хостинг упирается в фиксированный выход и подпись без присмотра; один self-hosted страдает от диска и конкуренции. Устойчивый шаблон: лёгкое на хостинге, тяжёлое в выделенном Mac-облаке, масштаб при SLA или регионе. По сравнению с офисными Mac, аренда Mac-облака даёт быстрый SSH в стиле VPS; по сравнению с бесконечными минутами — часто прозрачнее годовой бюджет. С Xcode Cloud помните: хостинг GitHub и self-hosted Mac-облако решают Git CI — зона ответственности веток должна быть ясной. Для выдачи узлов почти как API читайте материал VPSMAC про API за 90 секунд и CI/CD.