Оптимизация runner GitHub Actions macOS: P95 −57 % + playbook iOS CI

Ниже — сводка benchmark и shadow quick start. Cache YAML, scoring model и checklist архитектуры — в связанных тематических статьях.

1. Почему GitHub Actions macOS / iOS CI медленный?

Команды застревают в разных местах. Эта страница остаётся на уровне обзора — переходите к теме, которая совпадает с вашим симптомом:

Если нужно только «насколько быстрее другой runner?», оставайтесь здесь: Benchmark и waterfall.

2. Результаты benchmark: насколько помогает выделенный Mac mini M4

iOS-команда 8 человек · CocoaPods · 25–40 PR/день · без изменений кода приложения, только смена runner. Данные warm build:

Сводка окружения: iOS-команда 8 человек · CocoaPods · 25–40 PR/день · Xcode 16.2 на обеих сторонах · Mac mini M4 16 ГБ + том данных 1 ТБ · 14-дневный shadow dual-run на 187 PR. Разделение cold/warm: статья про дисперсию сборки; воспроизведение: Shadow quick start.

4:00–5:00 |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■ 52%
5:00–6:00 |■■■■■■■■■■■■■■■■■■ 28%
6:00–7:00 |■■■■■■ 10%
P95 6:05   |■■■■■■■■■■■■■■

3. Waterfall времени P95: 14:12 → 6:05 (−57 %)

Главная диаграмма для шаринга — откуда 8m 07s экономии:

macos-latest  P95 ████████████████████████ 14:12
                              │
  Очередь убрана −4:50  ████████████░░░░░░░░░░░░
  cache/Pods    −1:40  ████░░░░░░░░░░░░░░░░░░░░
  xcodebuild    −1:15  ███░░░░░░░░░░░░░░░░░░░░░
  Sign/upload   −0:20  █░░░░░░░░░░░░░░░░░░░░░░░
                              ▼
self-hosted   P95 ██████████ 6:05  (−57%)

Только очередь ≈ −4:50 → тема очереди. Cache ≈ −1:40 → гайд по cache.

4. Выберите статью под вашу проблему

Темы идут в типичном порядке troubleshooting — начните с того, что болит сильнее:

Болит очередь?
  → Почему macos-latest в очереди (в подготовке)
  → Эта страница: benchmark + waterfall

Время сборки скачет?
  → iOS CI тормозит (опубликовано)
  → Гайд по cache Pods/SPM/DerivedData (опубликовано)

Решаете купить или арендовать?
  → Shadow-данные на этой странице
  → ROI: купить vs арендовать (в подготовке)
  → Тарифы Cloud Mac / FAQ CI/CD

Нужны multi-runner или fallback?
  → Архитектура self-hosted (в подготовке)

5. Навигация по темам

Каждая статья закрывает одну конкретную проблему. Эта страница даёт обзор benchmark и ссылки.

Опубликованные связанные статьи: Primer CI Mac mini M4 · ROI engineering-hours · FAQ CI/CD

6. Shadow benchmark quick start

Ниже — минимальные шаги воспроизведения. Полный workflow и checklist rollout: тема архитектуры; cache YAML: гайд по cache.

1. Скопировать ios-ci.yml → ios-ci-shadow.yml; добавить job с runs-on: [self-hosted, macos-m4-ios]
2. Dual-run каждый PR против macos-latest с тем же commit SHA 7–14 дней
3. Записывать wall time P50/P95 и время очереди; считать warm build P95 отдельно (определение в iOS CI тормозит?)
4. Сравнить failure rate, затем читать ROI: купить vs арендовать

on:
  pull_request:
    branches: [main, release/*]
jobs:
  ios-hosted:
    runs-on: macos-latest
  ios-shadow:
    runs-on: [self-hosted, macos-m4-ios]
    # same steps · same SHA

7. FAQ

Насколько быстрее self-hosted runner GitHub Actions macOS по сравнению с macos-latest?

В этом прогоне: warm build P95 −57 % (14:12→6:05), σ −40 %. См. Benchmark; воспроизвести через Shadow quick start.

Почему runner'ы GitHub Actions macOS стоят в очереди?

Общий hosted pool + всплеск concurrency в release week. Время очереди не тарифицируется, но входит в wall time. Полный разбор → тема очереди.

Self-hosted runner'ы менее стабильны?

Зависит от ops: запас диска, надзор runner, signing assets. Сравнивайте failure rate в shadow; здесь за 14 дней 8,0 % → 3,2 %. macos-latest как fallback снижает воспринимаемый риск.

Стоит ли Mac mini как CI runner?

Имеет смысл при 20+ PR/день с ухудшающейся очередью. При <50 сборок/месяц hosted может хватить. Scoring model и TCO → ROI: купить vs арендовать.

Какие ограничения у GitHub macos-latest?

Общая очередь, эфемерные workspace, нестабильный cache между job'ами, конкуренция I/O. Нельзя закрепить DerivedData или убрать очередь.

Как оптимизировать P95 iOS CI?

Очередь → cold/warm → cache → concurrency → железо. Пошагово: очередь · дисперсия сборки · гайд по cache.

Как оптимизировать cache CocoaPods?

Полный YAML и дизайн ключей → гайд по cache.

Сколько длится миграция?

1–2 дня подготовки + shadow 7–14 дней + постепенный rollout 3–5 дней. Сначала shadow только с тестами, signing импортировать позже.

8. Итог

После перехода на self-hosted runner warm P95 снизился с 14:12 до 6:05, дисперсия заметно сузилась. Эта страница показывает benchmark и waterfall; очередь, дисперсия сборки, cache, ROI и архитектура — в отдельных статьях. Перед покупкой железа проведите shadow dual-run на своих данных.