iOS CI тормозит? Почему xcodebuild на GitHub Actions «плавает»

1. CI как лотерея: тот же commit, другое время

Если вы искали iOS CI тормозит? Почему xcodebuild на GitHub Actions «плавает», эти картины знакомы:

• Тот же commit, re-run — wall clock 2–3× разница
• P95 на дашборде красный, ощущение команды: «merge обычно не так долго ждём»
• pod install то 30 секунд, то «завис»
• В пятницу после обеда merge не жмут — боятся медленного прогона

Не всегда не хватает CPU. В 14-дневном Shadow с командами чаще: цифры смешали, среда нестабильна — cache не держится, диск в contention. Смена чипа — в самом конце.

Эта полевая заметка про одно: почему сборки скачут. Job в очереди? → статья про очередь. Cache, купить vs аренда → cluster cache и ROI.

2. cold и warm: не в одну кучу

Классическая ловушка: все времена сборок в один P95. Редкие cold тянут хвост — данные кричат «каждый день медленно», merge в быту говорит иначе.

2.1 Когда становится cold

На macos-latest cold чаще — workspace после job чистят, cache не «приживается»:

Частые Pod-апгрейды → больше cold. Не деградация железа — другая работа на этой неделе. Отчитывайте «неделю Pod» и «обычную dev-неделю» раздельно.

2.2 Почему warm всё равно нестабилен

Даже только warm: wall clock может гулять ~30 %. Часто:

• cache miss: ключ без arm64, ветка не привязана, job'ы делят слот
• много macOS job'ов в org → диск и сеть тормозят друг друга
• то только main, то полные unit+UI — разная нагрузка
• объём изменений: исходники Pod vs одна строка SwiftUI — разный compile

3. Куда уходит время

Проставьте таймстемпы по step'ам workflow — wall clock делится на пять блоков. Распределение warm (зависит от проекта):

① checkout + env setup        ~0:30 – 1:30
② pod install / SPM resolve   ~0:30 – 2:00   (cold ↑↑)
③ xcodebuild compile+link      ~3:00 – 8:00   (объём изменений кода)
④ tests (simulator / unit)    ~1:00 – 6:00   (опционально, часто недооценено)
⑤ archive + codesign           ~1:00 – 4:00   (release pipeline)

warm P50 total typical: 6 – 14 min

На практике: длительность step'ов или time для pod install, xcodebuild build, xcodebuild test. Блок ② >5 мин → cold/cache; ③ скачет → DerivedData/concurrency; ④ всегда длинный → вынести тесты или nightly.

4. Тесты и подпись: скрытые тормоза

Много «xcodebuild медленный» на деле — тесты или подпись в той же сборке:

• cold start симулятора: первый boot на CI — без прогрева каждый job заново
• UI tests на порядок медленнее unit; в одном job с compile → некрасивый P95
• сертификаты, Keychain, profiles — на hosted runner часто настраивают каждый job
• archive/IPA — release pipeline, не PR-валидация

5. 14 дней Shadow

Двойной трек: macos-latest и выделенный Mac mini M4, по 187 PR, Xcode 16.2 / CocoaPods 1.15.2 выровнены. Методика: benchmark pillar.

cold+warm в одном P95 → повседневный опыт завышен ~15–25 % → «срочно покупать железо». Лучше: merge = warm, недели Pod = cold отдельно.

На выделенном M4 warm всё равно быстрее cold — DerivedData/Pods с постоянным «домом» окупается. Подробнее: cluster cache.

6. Порядок: ясность → cache

После очереди (или если она мала) — не начинать с покупки:

1. тегировать сборки: cold vs warm (Podfile.lock, cache hit)
2. SLA только warm P95; cold — еженедельно или отдельная линия
3. стратегия cache DerivedData, Pods, SPM — best practices cache (в подготовке)
4. не перегружать macOS job'ы: self-hosted 1–2 параллельно; hosted — меньше общего workspace
5. разделить PR-валидацию и release/signing
6. cache не хватает → M4 / M4 Pro — чип и инженерные часы

- name: Classify build type
  run: |
    if git diff --name-only HEAD~1 | grep -q Podfile.lock; then
      echo "BUILD_TYPE=cold" >> $GITHUB_ENV
    else
      echo "BUILD_TYPE=warm" >> $GITHUB_ENV
    fi

- name: Record wall clock
  run: |
    echo "build_type=${BUILD_TYPE}" >> metrics.csv
    echo "wall_sec=$(( $(date +%s) - START ))" >> metrics.csv

7. FAQ

2–3× на том же commit — нормально?

На macos-latest да: один раз полный cache hit, другой miss плюс очередь. Сначала сравните pod install и логи cache, не меняйте чип сразу.

Как правильно считать P95?

Ощущение merge: P95 warm, ~30 сэмплов за две недели. cold отдельно — вместе искажает закупки.

pod install всегда медленный — вина CocoaPods?

На hosted runner чаще: Pods без постоянного места, cache key без ветки/архитектуры. Self-hosted с фиксированным диском: warm часто <30 сек.

Mac mini M4 уберёт разброс?

warm P95 −57 %, σ −40 % — но без разделения cold/warm и дизайна cache пики останутся и на выделенной машине.

Очередь или сама сборка?

Начало лога: Waiting for a runner. Очередь в wall clock, не в минутах GitHub. Очередь ≈0, а медленно — сторона сборки этой заметки → cache.

Читать дальше?

YAML cache → cluster cache; купить vs аренда → ROI и 500 сборок/месяц.

8. Итог

«iOS CI медленный» на GitHub Actions редко сводится к CPU. Чаще накладывается:

1. cold и warm в одном P95
2. hosted job чистит диск → cache не держится
3. тесты, подпись и PR-build в одном job

Сначала честный warm P95, потом cache → concurrency → железо. За 14 дней Shadow метрики + cache хватили, чтобы warm P95 ушёл с 14:12 до 6:05 — без поспешного решения о покупке.

Читать также

• Оптимизация self-hosted runner GitHub Actions macOS: P95 −57 % (pillar)
• Почему iOS CI/CD в 2026 крутится на Mac mini M4
• 500 iOS-сборок в месяц: купить Mac mini или арендовать Cloud Mac?
• x86 vs Apple Silicon: iOS CI/CD и инженерные часы M4 Pro