Conclusion en 30 secondes : mesurez la file avant de louer

GitHub précise qu’un travail destiné à un runner auto-hébergé reste en attente lorsqu’aucun runner en ligne, disponible et correspondant aux critères de routage ne peut le prendre en charge (règles de disponibilité et de mise en attente des runners). Pour le dimensionnement des nœuds Mac pour la CI iOS d’entreprise, ne convertissez donc pas le nombre de développeurs en nombre de machines. Commencez cette semaine par extraire les files d’attente et les durées réelles, séparez les charges selon leurs contraintes, puis validez la capacité de base avec un essai avant de louer des nœuds supplémentaires.

À qui s’adresse cette méthode ?
Aux responsables IT qui préparent une demande d’achat ou de location de ressources Mac pour la CI iOS.
Aux équipes plateforme qui règlent le routage et les files de GitHub Actions auto-hébergé.
Aux responsables FinOps qui ont besoin d’un modèle de capacité et de budget que l’on peut recalculer.

Première étape : distinguer le travail Mac du reste de la chaîne

Compter les dépôts ou les développeurs ne révèle pas la charge réellement envoyée aux Mac. Une chaîne peut lancer des tâches de lint, de vérification de fichiers ou de génération de documentation qui n’ont pas besoin de macOS. À l’inverse, une compilation Xcode ou un test sur simulateur ne peut pas simplement être déplacé vers un runner générique sans vérifier les dépendances de l’étape.

Dressez l’inventaire des workflows et classez chaque tâche selon son environnement requis. Pour chaque exécution, relevez son type de déclenchement, son heure de mise en file, son heure de démarrage, sa durée, son résultat et les étiquettes de runner demandées. Les événements workflow_job fournissent notamment des événements et des états exploitables pour observer le cycle de vie des tâches (documentation des événements workflow_job). Vous pouvez ainsi calculer vous-même le délai entre la mise en attente et le démarrage, au lieu de confondre attente et temps de compilation.

Le routage doit correspondre à l’environnement dont la tâche a réellement besoin. GitHub décrit la sélection par groupes et étiquettes dans la configuration des workflows (choix du runner pour un travail). Vérifiez aussi les étiquettes disponibles et leur usage (documentation sur les étiquettes des runners auto-hébergés). Une étiquette trop large peut envoyer un travail vers une machine inadaptée ; une combinaison trop restrictive peut laisser un nœud inutilisé pendant qu’une tâche compatible attend.

Comment estimer le nombre de GitHub Actions auto-hébergés sur Mac à partir de l’attente ?
Ne divisez pas le temps d’attente par une durée moyenne de compilation pour obtenir directement un nombre de machines. Segmentez d’abord les jobs par groupe, étiquettes et contraintes, puis rapprochez les périodes d’attente de la durée d’exécution et du nombre de jobs simultanément éligibles. Une file qui apparaît uniquement lors d’une vague de PR appelle une décision différente d’une attente régulière sur les builds de branche principale.

Gardez également séparées les limites de concurrence propres aux workflows GitHub Actions et la capacité de votre parc auto-hébergé. Les premières sont documentées par GitHub, mais elles ne constituent pas une recommandation de configuration pour vos Mac (limites de GitHub Actions). Votre parc ne peut traiter que les jobs qui lui sont effectivement routés et que les nœuds disponibles peuvent exécuter.

PR, branche principale et pointes : la même machine n’absorbe pas toujours la même charge

Les vérifications de pull request sont souvent sensibles au délai de retour : une file d’attente visible ralentit la revue, même si la compilation finit par réussir. Les builds de branche principale peuvent être moins urgents, tandis qu’un ensemble de validations déclenché par des merges rapprochés provoque une pointe brève. Pour chaque catégorie, relevez le volume observé sur vos propres workflows, la durée constatée et le niveau de simultanéité effectivement demandé. N’utilisez pas une moyenne globale si elle mélange builds courts et compilations complètes.

Distinguez aussi les étapes transférables des étapes liées à macOS. Déplacer vers des runners non-Mac les vérifications qui n’exigent ni Xcode ni environnement Apple permet d’éviter de compter deux fois toute la chaîne comme charge Mac. À l’inverse, les tâches nécessitant un SDK, une version d’Xcode ou une architecture particulière doivent rester dans le périmètre des nœuds compatibles.

Scénario de CI Données à relever Contrainte à vérifier Décision de capacité
Vérification de PR Déclenchements, durée réelle, attente et jobs simultanés Retour rapide attendu par les développeurs ; étapes réellement liées à macOS Dimensionner le pool partagé à partir des pointes observées, pas de l’effectif
Build de branche principale Fréquence, durée et recouvrement avec les PR Priorité et tolérance à l’attente Autoriser le partage si les tâches sont compatibles et que l’attente reste acceptable
Simulateur et régression Durée, parallélisme des tests et matrice d’exécution Version du simulateur, mémoire et stabilité des suites Isoler ou limiter les tests si leur concurrence perturbe les builds prioritaires
Signature et publication Durée, créneau de publication, accès aux secrets Approbations, environnement protégé et identité de signature Réserver un pool séparé si la politique de sécurité ou le routage l’impose
Outil ou chaîne héritée Versions de macOS, Xcode et architecture requises Compatibilité avec les autres travaux Maintenir une capacité dédiée si la tâche ne peut pas partager le pool standard

Un tableau de ce type ne fixe pas combien de Mac louer : il rend visible ce qu’il faut mesurer avant de prendre cette décision. Utilisez les données de vos workflows plutôt que des durées-types non vérifiées.

Simulateurs et régressions : mesurer la concurrence utile, pas le nombre de tests

Une suite de tests peut être longue sans exiger autant de nœuds que de cas de test. Ce qui détermine la demande, c’est le nombre de jobs réellement exécutés en parallèle, les ressources consommées par chacun et la possibilité de les répartir sans conflit. Notez séparément les tests de PR, les campagnes de régression planifiées et les matrices qui lancent plusieurs variantes de configuration.

Vérifiez ensuite si les builds ordinaires et les tests simulateur peuvent cohabiter. Un partage peut réduire les périodes d’inactivité, mais il devient contre-productif si les tests saturent les ressources nécessaires aux compilations ou font dépasser le délai de retour attendu pour les PR. Une séparation ne se justifie pas parce que les tests semblent lourds : elle doit répondre à une contrainte mesurée, à un objectif d’attente ou à une incompatibilité technique.

Faut-il séparer les builds de PR, les simulateurs et les tâches de signature ?
Pas systématiquement. Partagez les nœuds lorsque les chaînes d’outils et les règles d’accès sont compatibles, que les files restent maîtrisées et que les résultats sont prévisibles. Créez des pools distincts lorsque les environnements ne peuvent pas cohabiter, que les travaux de publication sont protégés par des approbations ou que les tests retardent de façon répétée les validations prioritaires.

Signature et publication : la capacité dépend aussi des droits

Un job de signature n’est pas un build ordinaire auquel on ajouterait une étape à la fin. Les certificats, profils, secrets et approbations déterminent quels runners peuvent exécuter la tâche et à quel moment. La capacité de calcul peut être disponible sans que le job soit autorisé à démarrer sur le nœud concerné. Il faut donc modéliser la charge et les restrictions d’accès séparément.

Documentez les tâches de publication avec leur créneau, leurs prérequis, leur durée enregistrée et leur règle d’approbation. Si plusieurs publications peuvent se chevaucher dans les faits, consignez ce chevauchement ; ne le déduisez pas d’une durée moyenne. Si une seule publication est autorisée à la fois par la politique de l’entreprise, ajouter des Mac ne supprimera pas ce verrou. Dans ce cas, le levier porte sur le processus ou la planification, pas sur le nombre de machines.

Les groupes de runners permettent d’organiser l’accès aux runners selon les dépôts ou les workflows autorisés (présentation des groupes de runners). Associez chaque groupe aux besoins réels de publication et faites confirmer les règles par les responsables sécurité. Le but n’est pas de placer tous les secrets sur un pool plus large pour accélérer la file : c’est d’éviter qu’une tâche sensible soit routée vers un nœud qui n’a pas à y accéder.

De la file au modèle : calculer base, pointe et capacité de réserve

Pour transformer vos enregistrements en estimation reproductible, utilisez des variables issues des workflows. Pour chaque famille de tâches (i), notez :

  • (N_i) : le nombre de tâches observées dans la période étudiée ;
  • (D_i) : leur durée d’exécution mesurée ;
  • (C_i) : la part de ces tâches qui se chevauche dans les périodes de pointe ;
  • (A_i) : la fraction des nœuds admissibles au routage de cette famille ;
  • (H_i) : le temps pendant lequel la capacité est réellement disponible.

Une estimation de charge moyenne peut s’exprimer sous la forme (\sum_i (N_i \times D_i) / H_i). Ce résultat n’est pas à lui seul un nombre de nœuds à louer : il ne décrit ni les pointes ni les contraintes d’éligibilité. Calculez donc la demande des périodes chargées à partir des jobs simultanés observés, puis retirez du pool les nœuds qui ne peuvent pas accepter la famille concernée. Définissez enfin une réserve selon l’objectif d’attente de votre équipe et vérifiez-la lors d’un essai ; ne présentez pas cette marge comme une valeur recommandée par GitHub.

Résultat du modèle Comment le construire avec vos relevés Usage dans la décision
Capacité de base Charge récurrente, durée mesurée et disponibilité des nœuds compatibles Déterminer le socle nécessaire au fonctionnement habituel
Capacité de pointe Jobs simultanés observés pendant les merges, régressions ou publications Vérifier si l’attente pendant les périodes chargées est acceptable
Capacité de réserve Marge définie selon l’objectif de service et les pointes constatées Décider si une capacité flexible est préférable à un achat permanent
Capacité isolée Jobs restreints par la chaîne d’outils, le groupe ou les droits de signature Éviter de compter un nœud incompatible comme ressource disponible

Ce modèle est une méthode interne de calcul, pas une formule officielle de GitHub. Les comptes, durées et seuils d’attente doivent venir de vos journaux et des objectifs de service convenus avec les équipes. Si vous ne disposez pas encore d’un historique suffisamment représentatif, conservez l’estimation comme hypothèse et faites-la confirmer par un essai contrôlé plutôt que de la convertir en engagement budgétaire définitif.

Pointes et outils hérités : une file temporaire n’est pas une pénurie permanente

Les campagnes de régression, les merges concentrés et les publications peuvent produire des files qui disparaissent une fois la vague passée. À l’inverse, une file récurrente, visible sur plusieurs périodes et pour les mêmes tâches compatibles, peut signaler un socle insuffisant. Examinez le début, la durée et la composition de chaque épisode : une attente ponctuelle sur un job peu prioritaire ne justifie pas la même réponse qu’un retard répété sur les validations de PR.

Les versions spécifiques de macOS ou de Xcode, les architectures particulières et les outils hérités compliquent le partage. Définissez des étiquettes qui traduisent ces exigences et vérifiez que les workflows les demandent réellement. Les runner groups et les labels orientent les tâches ; ils ne garantissent pas que deux environnements soient compatibles ni qu’un nœud soit disponible. La documentation de mise à l’échelle des runners décrit des mécanismes de gestion de capacité, mais leur configuration et leur exploitation restent à adapter à votre environnement (concepts des ensembles de mise à l’échelle, déploiement des ensembles de mise à l’échelle). Ne transposez pas ces instructions sans vérifier le mode d’hébergement choisi.

Comment faire évoluer le parc lorsque la charge iOS varie ?
Si les files n’apparaissent que pendant des pointes prévisibles, comparez le coût d’un socle stable assorti d’une capacité flexible au coût d’un parc dimensionné en permanence pour le maximum. Si l’attente se répète sur la charge courante, validez d’abord le routage, les jobs bloqués et la durée des étapes ; ensuite seulement, ajoutez de la capacité. Une capacité élastique n’est utile que si elle peut être fournie dans le délai de la pointe et avec les outils et droits requis.

Pour un modèle économique réaliste, intégrez les périodes d’inactivité, l’administration, les mises à jour, les essais après changement d’outil, la gestion des accès et le temps consacré aux incidents. Le montant affiché pour une machine ne représente pas à lui seul son coût complet. Si la location fait partie des options, confrontez vos besoins de durée et de configuration aux tarifs et périodes de location Mac affichés, sans extrapoler un prix à partir d’une capacité qui n’est pas confirmée.

Calendrier de validation : essai avant engagement durable

Au démarrage de l’essai, récupérez les données de file et d’exécution disponibles, vérifiez la cohérence des étiquettes et séparez les étapes Mac des étapes transférables. Notez également les contraintes de versions, de groupe et de signature. Le résultat attendu est un inventaire de familles de tâches, pas encore une demande d’achat.

Pendant la période de mesure, suivez chaque famille sur les périodes ordinaires et chargées. Comparez attente, durée, chevauchement, taux de réussite et disponibilité des nœuds. Définissez avant l’essai quel délai de retour est acceptable pour les PR et quelles publications peuvent attendre ; sinon, vous ne saurez pas si la capacité observée est suffisante.

À la revue de capacité, recalculer le modèle avec les observations de l’essai. Distinguez une file causée par un manque de nœuds d’une file provoquée par des labels trop précis, un groupe non autorisé ou une politique de publication. Soumettez les hypothèses de pointe et de réserve aux responsables plateforme, sécurité et finances.

Avant un engagement durable, comparez le socle requis avec les besoins variables. La documentation de GitHub recommande de traiter avec soin la gestion des runners éphémères et la mise à l’échelle ; la décision doit inclure leur cycle de vie et leur exploitation, pas seulement l’ajout de capacité (référence sur les runners auto-hébergés). Un runner éphémère peut réduire certains risques liés à la réutilisation d’un environnement, mais sa mise en œuvre demande aussi de vérifier la collecte des journaux, le nettoyage et le délai de provisionnement.

Utilisez cette liste avant de signer une demande de capacité :

  • [ ] Les jobs qui exigent macOS ou Xcode sont séparés des étapes transférables.
  • [ ] Les durées et attentes proviennent des enregistrements de vos workflows.
  • [ ] Les pics de PR, de simulateur, de régression et de publication sont étudiés distinctement.
  • [ ] Les labels et groupes correspondent aux contraintes réelles de chaque tâche.
  • [ ] Les jobs de signature sont routés selon les droits et approbations définis par la sécurité.
  • [ ] La capacité de base, la pointe et la réserve sont calculées séparément.
  • [ ] L’essai confirme les hypothèses avant l’achat, la location ou l’extension du parc.

Si votre solution actuelle repose sur des Mac achetés pour absorber le maximum, elle immobilise du budget pendant les périodes calmes, laisse à votre équipe la maintenance matérielle et oblige à prévoir les pointes en avance. À l’inverse, l’exécution locale peut compliquer la disponibilité partagée et la continuité des équipes réparties. La location n’est pas automatiquement préférable si votre charge est stable et permanente ou si vos tâches exigent des interfaces physiques particulières ; mais pour tester un pool, couvrir une pointe ou éviter un achat prématuré, comparer une capacité Mac distante à vos relevés est une option concrète. Après validation de la configuration et du mode de livraison nécessaires, vous pouvez examiner les options de location Mac à distance de VMSPIN et demander un essai de capacité adapté aux tâches réellement mesurées.