Optimisation runner GitHub Actions macOS : P95 −57 % + playbook CI iOS

Ci-dessous : résumé du benchmark et shadow quick start. YAML cache, modèles de scoring et checklists d'architecture se trouvent dans les articles thématiques liés.

1. Pourquoi GitHub Actions macOS / CI iOS est lent ?

Les équipes restent bloquées à des endroits différents. Cette page reste au niveau vue d'ensemble — allez au sujet qui correspond à votre symptôme :

Si vous voulez seulement « combien plus rapide avec un autre runner ? », restez ici : Benchmark et waterfall.

2. Résultats benchmark : l'apport du Mac mini M4 dédié

Équipe iOS 8 personnes · CocoaPods · 25–40 PR/jour · aucun changement de code app, seul le runner change. Données warm build :

Résumé environnement : équipe iOS 8 personnes · CocoaPods · 25–40 PR/jour · Xcode 16.2 aligné des deux côtés · Mac mini M4 16 Go + volume données 1 To · shadow dual-run 14 jours sur 187 PR. Séparation cold/warm : article sur la variance de build ; reproduction : Shadow quick start.

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

3. Cascade temps P95 : 14:12 → 6:05 (−57 %)

Le graphique partageable — d'où viennent 8m 07s d'économies :

macos-latest  P95 ████████████████████████ 14:12
                              │
  File supprimée −4:50  ████████████░░░░░░░░░░░░
  cache/Pods    −1:40  ████░░░░░░░░░░░░░░░░░░░░
  xcodebuild    −1:15  ███░░░░░░░░░░░░░░░░░░░░░
  Sign/upload   −0:20  █░░░░░░░░░░░░░░░░░░░░░░░
                              ▼
self-hosted   P95 ██████████ 6:05  (−57%)

La file seule ≈ −4:50 → sujet file. Cache ≈ −1:40 → guide cache.

4. Choisir l'article adapté à votre problème

Ces sujets suivent un ordre de dépannage typique — commencez par ce qui fait le plus mal :

Problème de file ?
  → Pourquoi macos-latest fait la queue (en préparation)
  → Cette page : benchmark + waterfall

Temps de build très variables ?
  → Les builds iOS semblent lents (publié)
  → Guide cache Pods/SPM/DerivedData (publié)

Acheter ou louer ?
  → Données shadow sur cette page
  → Acheter vs louer ROI (en préparation)
  → Forfaits Mac cloud / FAQ CI/CD

Setup multi-runner ou fallback ?
  → Architecture auto-hébergée (en préparation)

5. Navigation thématique

Chaque article couvre un problème concret. Cette page regroupe la vue d'ensemble du benchmark et les liens.

Articles connexes publiés : Primer CI Mac mini M4 · ROI heures d'ingénierie · FAQ CI/CD

6. Shadow benchmark quick start

Étapes minimales de reproduction ci-dessous. Workflow complet et checklist de déploiement : sujet architecture ; YAML cache : guide cache.

1. Copier ios-ci.yml → ios-ci-shadow.yml ; ajouter un job avec runs-on: [self-hosted, macos-m4-ios]
2. Dual-run chaque PR contre macos-latest avec le même commit SHA pendant 7–14 jours
3. Enregistrer P50/P95 mural et temps de file ; calculer warm build P95 séparément (définition dans l'article sur la variance de build)
4. Comparer taux d'échec, puis lire acheter vs louer ROI

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

Combien un runner GitHub Actions macOS auto-hébergé peut-il être plus rapide que macos-latest ?

Ce run : warm build P95 −57 % (14:12→6:05), σ −40 %. Voir Benchmark ; reproduire via Shadow quick start.

Pourquoi les runners GitHub Actions macOS font-ils la queue ?

Pool hébergé partagé + forte concurrence en semaine de release. Le temps de file n'est pas facturé mais compte au temps mural. Détail complet → sujet file.

Les runners auto-hébergés sont-ils moins stables ?

Dépend de l'ops : seuils disque, supervision runner, matériel de signature. Comparez les taux d'échec en shadow ; ici taux 14 jours 8,0 % → 3,2 %. Garder macos-latest en fallback réduit le risque perçu.

Un Mac mini vaut-il le coup comme runner CI ?

À évaluer à 20+ PR/jour avec file qui empire. Sous ~50 builds/mois, l'hébergé peut suffire. Modèle de scoring et TCO → acheter vs louer ROI.

Quelles sont les limites de GitHub macos-latest ?

File partagée, workspaces éphémères, cache instable entre jobs, contention I/O concurrente. Impossible de fixer DerivedData ou d'éliminer la file.

Comment optimiser le P95 de la CI iOS ?

File → cold/warm → cache → concurrence → matériel. Pas à pas : file · variance de build · guide cache.

Comment optimiser le cache CocoaPods ?

YAML complet et design des clés → guide cache.

Combien de temps prend la migration ?

1–2 jours préparation + shadow 7–14 jours + bascule progressive 3–5 jours. Commencer shadow avec tests seulement, importer la signature ensuite.

8. Conclusion

Après le passage aux runners auto-hébergés, le warm P95 est passé de 14:12 à 6:05 avec une variance bien plus serrée. Cette page montre le benchmark et le waterfall ; file, variance de build, cache, ROI et architecture ont chacun un article dédié. Lancez un shadow dual-run avec vos propres données avant de vous engager sur du matériel dédié.