Runners macOS hébergés par GitHub ou Mac dédié, chiffrés honnêtement
Le tarif à la minute n’est que le début de la comparaison. Les runners macOS hébergés vous facturent aussi un travail qu’une machine chaude ne referait pas. Ils coûtent aussi du temps d’ingénieur en files d’attente. Cette page compare les deux options à trois niveaux d’usage réalistes, avec chaque hypothèse énoncée.
Les hypothèses
- macOS hébergé facturé $0.062 la minute, le tarif du runner standard, arrondi à la minute supérieure par job.
- Un runner hébergé à froid passe environ 3 minutes par job à restaurer les dépendances et à reconstruire ce qu’un cache chaud aurait gardé. Ce temps est facturé.
- Un M6 mini dédié à prix fixe de $139 par mois, caches chauds, sans restauration à chaque job.
- GitHub ne facture pas l’attente, mais elle est bien réelle. L’attente d’un runner macOS dure souvent quelques minutes aux heures chargées.
Trois équipes, un mois
light steady heavy
jobs per month 120 400 900
minutes per job 8 10 12
billed on hosted 1,320 min 5,200 min 13,500 min
incl. cache restore (360) (1,200) (2,700)
hosted cost $82 $322 $837
dedicated M6 $139 $139 $139
monthly difference -$37 +$203 +$718L’équipe légère (light) doit rester sur les runners hébergés. L’équipe régulière (steady) économise deux cents dollars environ par mois et obtient des builds plus rapides. L’équipe intensive (heavy) paie chaque mois plusieurs fois le prix d’une machine, et en obtient une plus lente.
D’où viennent les minutes cachées
Chaque job hébergé part d’une image propre. Il retélécharge donc les paquets SwiftPM, CocoaPods et des morceaux du runtime du simulateur. Puis il reconstruit DerivedData de zéro. Sur un vrai projet, cela fait plusieurs minutes facturées par job avant que votre code ne compile. Sur une machine dédiée, ces artefacts persistent. Le deuxième build de la journée reprend donc là où le premier s’est arrêté.
La vitesse, pas seulement l’argent
Le cache chaud qui supprime des minutes facturées supprime aussi des minutes d’attente réelle. Les équipes qui passent un build hébergé de 12 minutes sur un Mac mini dédié avec cache chaud le voient souvent finir en 4 à 6 minutes. Aucune file d’attente ne le précède. C’est la différence entre une pull request vérifiée avant ou après le déjeuner.
Ce qu’un Mac dédié ne règle pas
- Les matrices parallèles. Une machine exécute un job à la fois. Découpez la matrice ou ajoutez des machines.
- Les dépôts publics. N’exécutez pas le code de pull requests non fiables sur une machine qui compte pour vous. Gardez ces jobs sur les runners hébergés.
- Quelqu’un doit l’exploiter. Les mises à jour, le service du runner, les effacements. C’est ce que fait MacRun pour le prix fixe. Sur une location de machine nue, c’est votre travail.
Faites vos propres calculs dans le calculateur, et consultez le tableau complet des tarifs sur la page des prix de GitHub Actions.
Questions fréquentes
Un Mac dédié coûte-t-il toujours moins cher que les runners macOS hébergés par GitHub ?
+
Non. Sous environ 2,242 minutes macOS par mois, la facturation à la minute coûte moins cher qu’une machine à prix fixe de $139. Au-dessus, le Mac dédié coûte moins cher, et l’écart grandit avec l’usage.
Pourquoi les runners hébergés facturent-ils plus de minutes que mon build n’en prend ?
+
Parce que chaque job part d’une image propre. Il passe des minutes facturées à restaurer les dépendances et à reconstruire les caches avant de compiler. Une machine dédiée chaude saute ce travail à chaque job après le premier.
Un Mac mini dédié est-il beaucoup plus rapide qu’un runner hébergé ?
+
Avec un cache chaud et sans file d’attente, un build hébergé de 12 minutes finit souvent en 4 à 6 minutes. Le gain exact dépend de la part de votre build consacrée aux dépendances et au cache.
Puis-je utiliser les deux à la fois ?
+
Oui, et beaucoup d’équipes le font. Lancez le build de la branche principale et la plupart des pull requests sur le Mac dédié. Gardez les larges matrices d’appareils et les jobs des dépôts publics sur les runners hébergés par GitHub.