GitHub Actions Runner Scale Set Client : le CI Mac 2026 vaut-il le coup ?

Une file de compilation Mac qui s’allonge pendant les pics de pull requests, alors que chaque nouveau Runner dépend encore d’une machine à fournir et à nettoyer.

La solution la plus rapide est de piloter un essai limité avec le GitHub Actions Runner Scale Set Client pour les tâches temporaires, tout en conservant un pool Mac préchauffé ou dédié pour la signature de production et les jobs sensibles au délai.

Qui devrait lire cet article ?
Vous administrez plusieurs dépôts GitHub Actions Mac Runner ou vous absorbez des pics de publication iOS et macOS.
Vous devez réduire les résidus entre projets, vérifier l’isolation d’un JIT Runner et arbitrer entre achat fixe, capacité Mac distante et pool hybride.

Dernière mise à jour : 20 septembre 2026. Les informations ont été vérifiées à partir du changelog GitHub du 5 février 2026, de la documentation officielle et du dépôt actions/scaleset.

SECTION 01Le premier indicateur : votre organisation peut-elle réellement fournir les Mac ?

Le GitHub Actions Runner Scale Set Client est un composant de raccordement, pas une usine complète de Mac. GitHub fournit le Scale Set API, la configuration JIT et le client ; votre entreprise reste responsable de l’approvisionnement du Mac, de l’initialisation de macOS, de la préparation de Xcode, du nettoyage et de la destruction de l’environnement. Cette frontière est explicitée dans le dépôt officiel actions/scaleset.

La décision ne doit donc pas commencer par « combien de Runners faut-il lancer ? », mais par « quelle action concrète crée un hôte disponible, et quelle action prouve qu’il est propre après le job ? ».

Utilisez cette matrice avant d’ouvrir un chantier d’automatisation :

Refusez l’élasticité en première intention si vous ne savez pas fournir automatiquement un Mac, si le nettoyage repose sur une simple commande dans le workspace, ou si aucun chemin de repli ne permet de terminer une livraison. À l’inverse, un pilote devient raisonnable lorsque votre équipe sait reconstruire l’hôte, transférer les journaux avant sa suppression et distinguer une tâche de validation d’une tâche qui manipule une identité de signature.

Le statut compte également : au 20 septembre 2026, GitHub présente encore Runner Scale Set Client comme une fonctionnalité en Public Preview, et non comme une capacité GA. Ne promettez donc pas à votre direction une interface immuable ni un comportement équivalent à une infrastructure de conteneurs. Vérifiez le dépôt officiel actions/scaleset avant chaque changement d’API ou d’exemple.

SECTION 02La capacité élastique réduit-elle vraiment la file d’attente ?

La métrique utile n’est pas le nombre d’événements reçus. Vous devez rapprocher plusieurs observations :

• TotalAssignedJobs représente la pression d’allocation observée par le Scale Set ;
• les jobs effectivement en cours indiquent la consommation réelle ;
• les jobs en attente mesurent le manque de capacité disponible ;
• le nombre de Mac que votre fabrique peut fournir borne la vitesse d’absorption ;
• le temps de démarrage détermine si une capacité théorique arrive encore à temps.

Le client ne doit donc pas transformer mécaniquement chaque message en une nouvelle machine. Une rafale de notifications peut concerner des jobs déjà attribués, annulés ou finalement exécutés par un Runner préexistant. Les mécanismes de message, de confirmation et de réattribution doivent être observés dans vos journaux et confrontés aux comportements décrits dans le README du Scale Set.

La comparaison à faire dans vos relevés

Création entièrement à la demande

• Avantage : peu de Mac restent inutilisés entre deux pics.
• Limite : provisionnement, déverrouillage, configuration Xcode et enregistrement du Runner s’additionnent avant le premier job.
• Usage approprié : validation de pull request ou compilation relançable, lorsque le délai supplémentaire est acceptable.

Capacité minimale préchauffée

• Avantage : les premiers jobs partent plus vite et la file absorbe les petites pointes.
• Limite : vous payez ou maintenez une capacité qui peut rester inactive.
• Usage approprié : équipe soumise à des pics réguliers, avec besoin de réduire le délai sans garder tout le parc actif.

Pool fixe de confiance

• Avantage : comportement connu pour la signature, les releases et les dépendances sensibles.
• Limite : les ressources sont immobilisées et une panne exige une procédure de remplacement.
• Usage approprié : archivage de production, certificats, profils et tâches dont le rerun n’est pas une solution acceptable.

Pour valider le gain, exportez vos files GitHub Actions, les heures de début et de fin de chaque job, le temps de fourniture d’un Mac et le nombre de tâches arrivant simultanément. Le guide GitHub de supervision et de dépannage rappelle que l’état du Runner et la santé de l’hôte ne sont pas la même chose. Un processus client actif sur un Mac indisponible ne constitue pas de la capacité.

SECTION 03L’isolation JIT protège-t-elle réellement le projet suivant ?

Un JIT Runner peut limiter la durée d’enregistrement d’un agent, mais il ne transforme pas automatiquement une machine réutilisée en environnement vierge. Vous devez gérer séparément quatre cycles :

1. Cycle du Runner : création de la configuration, connexion à GitHub, exécution puis désenregistrement.
2. Cycle de l’hôte macOS : réservation, démarrage, déverrouillage, disponibilité réseau et destruction.
3. Cycle du workspace : sources, produits Xcode, DerivedData, caches de dépendances et fichiers temporaires.
4. Cycle de l’identité de signature : trousseau, certificats, profils, secrets et session de compte.

Cette séparation est indispensable pour un self-hosted Mac Runner. Un Runner qui se désenregistre correctement peut laisser des sources, des caches ou une clé dans le trousseau si l’hôte reste en service. La référence GitHub sur l’utilisation sécurisée recommande de traiter les Runner auto-hébergés avec prudence, en particulier lorsque des workflows ou des contributions ne sont pas entièrement fiables.

Le cas d’une équipe audio, vidéo ou design

Une compilation d’application audio peut télécharger des bibliothèques propriétaires ; un projet vidéo peut produire des fichiers volumineux dans un répertoire temporaire ; une application de design peut conserver des ressources de test dans les caches Xcode. Le nettoyage du seul répertoire du dépôt ne couvre pas nécessairement ces emplacements, ni les journaux d’outils installés au niveau du système.

Pour ces charges, définissez une politique de destruction qui ne dépend pas de la bonne volonté du job. Si la commande de post-traitement échoue, l’orchestrateur doit marquer le Mac comme non réutilisable, sauvegarder les diagnostics autorisés, puis le reconstruire ou le supprimer. Un environnement JIT partagé entre une branche de confiance et une branche non vérifiée ne doit pas recevoir de certificats de production.

Les groupes de Runner et leurs règles d’accès doivent également refléter cette séparation. Consultez la documentation GitHub sur les groupes et l’accès aux Runner avant de créer un routage commun pour des dépôts ayant des niveaux de confiance différents.

SECTION 04Les délais de démarrage annulent-ils le bénéfice de l’élasticité ?

Mesurez le démarrage par étapes, et non comme un seul chronomètre :

• Mac alloué et joignable ;
• système déverrouillé et session de service opérationnelle ;
• outils et variables de sécurité disponibles ;
• Runner enregistré avec sa configuration JIT ;
• Xcode et les composants nécessaires initialisés ;
• premier job accepté par le Runner.

Cette décomposition vous indique où agir. Si le Mac est disponible mais que Xcode doit encore préparer un composant, augmenter le nombre de messages d’allocation ne corrigera pas l’attente. Si l’hôte est prêt mais que l’enregistrement échoue, le problème se trouve dans l’authentification, les permissions ou le transport, pas dans la capacité physique.

Le référentiel officiel des Runner auto-hébergés doit servir de base pour vérifier les prérequis du Runner. Pour l’authentification du client, contrôlez aussi les permissions et le modèle décrit dans la section officielle consacrée à l’authentification du Scale Set. N’accordez pas un jeton plus large simplement pour contourner une erreur de démarrage.

Première étape : construire une mesure reproductible

Choisissez une compilation qui peut être relancée sans certificat de production. Enregistrez séparément chaque transition, depuis la demande de capacité jusqu’à l’acceptation du job. Répétez la mesure sur une période représentant une activité normale et une période de publication, sans transformer ces observations en promesse générale de performance.

Ensuite, comparez trois politiques :

• zéro préchauffage : toutes les machines sont demandées au besoin ;
• petit socle préchauffé : une capacité minimale reste disponible ;
• pool fixe plus débordement : les jobs ordinaires utilisent le parc permanent, les pointes vont vers le Scale Set.

La bonne politique dépend de votre distribution réelle des arrivées et du coût d’un job retardé. Elle ne peut pas être déduite d’un nombre de nœuds arbitraire.

SECTION 05Contrôle, journaux et reprise forment le vrai plan de continuité

Le contrôle doit répondre à trois questions opérationnelles : qui peut demander un Runner, comment une attribution est confirmée, et que se passe-t-il si le client, le fournisseur Mac ou le réseau disparaît ?

Le REST API des Runner auto-hébergés permet de vérifier les objets et états exposés par GitHub, mais il ne remplace pas l’état de votre fournisseur d’hôtes. Conservez donc un identifiant corrélant le job, la configuration JIT, le Runner, l’hôte Mac et le lot de journaux.

Avant destruction, transférez vers un stockage externe les journaux d’initialisation, d’enregistrement, d’exécution et de nettoyage. Limitez leur contenu : un journal de commande peut révéler un chemin sensible, une variable ou un fragment de secret. La conservation doit être compatible avec votre politique de sécurité, tandis que les certificats et profils de signature ne doivent jamais être archivés avec les diagnostics ordinaires.

Préparez au minimum les chemins suivants :

• le client tombe avant l’enregistrement : le Mac est marqué comme incomplet et n’est pas réutilisé ;
• la fourniture échoue : le job revient dans la file ou est dirigé vers le pool fixe ;
• le Mac devient injoignable : l’orchestrateur cesse de l’annoncer comme capacité ;
• le nettoyage échoue : l’hôte est isolé, puis reconstruit ou supprimé ;
• le Scale Set est indisponible : les tâches admissibles basculent vers un pool permanent ou un Mac distant de secours.

Le but de l’acceptation n’est pas de démontrer que le processus redémarre. Il faut démontrer qu’un job peut revenir à une capacité fiable sans intervention manuelle sur chaque machine.

SECTION 06Le TCO doit comparer la capacité et le risque, pas seulement les machines

Votre modèle de coût doit rester paramétrique. Sans tarifs vérifiés pour la configuration, la région et le cycle de location retenus, toute économie exprimée en euros ou en pourcentage serait trompeuse.

Calculez séparément :

• capacité fixe réservée ;
• capacité préchauffée minimale ;
• capacité Mac créée à la demande ;
• automatisation de provisionnement et de destruction ;
• stockage externe des journaux ;
• supervision et astreinte ;
• maintenance de Xcode, des dépendances et des certificats ;
• coût des échecs, des reruns et des files pendant une publication ;
• coût d’un chemin de reprise.

Le pool élastique est souvent pertinent pour les validations de pull request, les tests de régression et les compilations reproductibles. Le pool fixe ou dédié reste préférable pour l’archivage de production, la signature et les jobs dont l’état doit être conservé sous contrôle. Apple Silicon doit être traité comme une contrainte de compatibilité et de capacité, pas comme une garantie que toutes les dépendances fonctionneront sans validation.

Si vous comparez l’achat de machines à une capacité distante, incluez l’immobilisation, le remplacement, l’espace, l’alimentation, la surveillance et le temps d’administration. Une offre de Mac distant MACNOX peut servir de point de comparaison pour un pilote, mais vous devez valider votre propre délai d’accès, votre procédure de nettoyage et votre scénario de bascule avant de l’intégrer au calcul final.

Décision finale selon vos preuves

Continuez avec le pool fixe si la charge est régulière, si la signature domine les exécutions et si vous ne pouvez pas encore prouver l’effacement d’un hôte.

Lancez un pilote limité si vous pouvez reconstruire les Mac, stocker les journaux hors nœud et mesurer le démarrage sur une charge sans secret de production. Commencez par une classe de jobs relançables, pas par la livraison de l’application.

Construisez un pool hybride si vos files varient fortement, si les validations peuvent être isolées et si les releases exigent un chemin préchauffé ou dédié. C’est le choix le plus défendable lorsque la réduction de file et le contrôle de l’identité de signature doivent coexister.

Questions fréquentes sur l’architecture

Les quatre réponses ci-dessous résument les limites à vérifier avant votre comité d’architecture.

Le client peut-il provisionner seul une machine Mac ?

Non. Il coordonne l’échange avec le Scale Set, mais le fournisseur de Mac et vos automatisations doivent créer, initialiser, surveiller et retirer l’hôte. Si cette couche manque, vous disposez d’un signal d’expansion, pas d’une capacité supplémentaire.

Kubernetes est-il obligatoire ?

Non. Kubernetes peut être retenu pour une partie du contrôle, mais une plateforme d’automatisation différente convient si elle sait gérer les états, les erreurs et les retours de capacité. Le choix d’orchestrateur ne remplace pas la gestion du cycle de vie macOS.

Le JIT Runner efface-t-il Xcode et les certificats ?

Non. Le désenregistrement du Runner ne prouve ni l’effacement du workspace, ni celui des caches, ni celui du trousseau. Une politique de destruction de l’hôte et une séparation stricte des identités sont nécessaires.

Où placer la signature de production ?

Dans un pool fixe ou dédié, avec accès restreint et procédure de reprise documentée. Le Scale Set peut traiter les étapes précédentes, mais une branche non fiable ne doit pas partager un environnement contenant une identité de signature.

Un remplacement direct du parc fixe par une capacité élastique vous exposerait à trois défauts concrets : un démarrage à froid au mauvais moment, des traces résiduelles si l’effacement est incomplet et une rupture de livraison lorsque le fournisseur Mac ou le client devient indisponible. Une location de Mac distant auprès de MACNOX peut offrir une capacité réelle et contrôlable pour un pilote, sans vous obliger à acheter immédiatement chaque machine ; utilisez-la toutefois pour éprouver le routage, la récupération et la bascule, plutôt que pour déplacer sans validation toute votre chaîne de signature de production. Pour examiner les modalités d’accès adaptées à votre organisation, consultez la page de commande Mac de MACNOX.

SECTION 07FAQ