Faire tourner plusieurs runners macOS auto-hébergés sur une même flotte semble simple jusqu'à ce que deux jobs touchent le même dossier, qu'un arbre DerivedData tiède se corrompe au milieu d'une compilation, ou qu'un week-end d'archives remplisse le volume de démarrage. En 2026 le débat n'est plus seulement « cloud ou on-prem » : il porte surtout sur quelles couches de cache et de disque sont partagées, cléifiées et nettoyées sous parallélisme réel. Cette note en style FAQ parcourt le cache GitHub Actions versus un SSD persistant local, comment éviter les courses au verrouillage lorsque les jobs se chevauchent, que faire avant que les disques deviennent critiques, et comment planifier le nettoyage des artefacts sans casser les exigences d'audit. Pour la vision plus large du dimensionnement d'un pool, voir aussi 2026 — Pool CI Mac en entreprise : parallélisme multi-dépôts, cache, disque — cloud ou auto-hébergé ?.
1. Cache Actions et disque persistant local : répartition des rôles
actions/cache (et les actions spécifiques aux dépendances) excellent pour les blobs portables cléifiés par fichiers de verrouillage et empreintes de toolchain : artefacts de résolution SwiftPM, toolchains téléchargées et binaires auxiliaires précompilés. Ils s'appuient sur les quotas du service GitHub et sur le chemin réseau : traitez-les comme une accélération au mieux, jamais comme la seule copie de ce que vous ne pourriez pas reconstruire. Un volume persistant local sur chaque Mac reste supérieur pour les compilations incrémentales sensibles à la latence et les très grands arbres que vous ne voulez pas repousser sur le WAN à chaque démarrage de job. Un schéma sain combine un cache distant à TTL court pour les entrées partageables, plus une racine d'espace de travail par runner sur SSD rapide avec sous-dossiers explicites par job ou dépôt, et une automatisation qui supprime les branches obsolètes après N jours. Documentez quels chemins ont le droit de persister entre jobs afin que la sécurité sache que les secrets ne peuvent pas s'accumuler silencieusement dans un arbre illimité.
2. Parallélisme sans courses : verrous, espaces de travail et files d'attente
La plupart des flakiness « mystérieuses » sur Mac partagés sont des courses sur le système de fichiers : deux workflows pointant par défaut vers le même emplacement DerivedData, des caches CocoaPods ou SPM sous un chemin global, ou des runtimes simulateur mis à jour pendant qu'un autre job démarre des appareils. Corrigez avec des préfixes stricts : dérivez DESTINATION et les dossiers de build à partir de l'identifiant d'exécution du workflow, montez ou cloisonnez des espaces de travail par job lorsque c'est possible, et n'exécutez jamais deux simulateurs GUI attachés au même jeu d'appareils sans file d'attente. Ajoutez des groupes de concurrence GitHub pour les jobs qui ne doivent pas se chevaucher sur une étiquette d'hôte, et plafonnez l'éventail de matrices par machine si vous opérez des runners fractionnaires. Pour les schémas d'orchestration sur plusieurs machines, le manuel
OpenClaw 2026 : déploiement et automatisation GitHub Actions
complète cette vue centrée sur le disque.
3. Quand les disques se remplissent : métriques, seuils et triage d'urgence
Traitez l'espace libre comme une métrique d'orchestration au même titre que le CPU : alertez à deux seuils — un avertissement où les jobs de nettoyage doivent s'intensifier, et un arrêt dur où les nouveaux jobs doivent être routés ailleurs. Journalisez des instantanés df -h dans votre observabilité et tracez la croissance par racine d'espace de travail afin de nommer le pire dépôt sans archéologie SSH. Conservez un volume scratch rapide pour les builds séparé du volume système lorsque le matériel le permet, afin qu'un disque de données plein ne bloque ni les éléments de connexion ni le service runner. L'élagage automatisé doit retirer des chemins sûrs par construction (anciens espaces d'exécution, caches simulateur remplacés) et ne jamais supprimer des artefacts sous conservation légale ; poussez les binaires vers du stockage objet et gardez les runners jetables.
4. Artefacts, journaux et fenêtre de nettoyage en entreprise
Les artefacts GitHub Actions facilitent les transferts entre jobs, mais les durées de rétention par défaut et les politiques d'organisation surprennent souvent les équipes réglementées. Alignez retention-days dans les workflows avec votre politique d'archivage, mettez en miroir les bundles critiques vers un stockage interne, et exécutez une tâche hebdomadaire qui liste les artefacts surdimensionnés avant que les utilisateurs ne constatent des échecs de téléchargement. Sur les disques auto-hébergés, associez des balayages TTL de dossiers à une fenêtre de maintenance explicite afin que l'astreinte anticipe de brèves pointes CPU. Si vous devez placer des démons sans présence humaine et discipliner les chemins sur macOS lui-même,
OpenClaw sur Mac distant : chemins, Docker et résidence locale
détaille launchd versus Docker avec les mêmes principes d'hygiène.
5. Checklist FAQ rapide pour les responsables plateforme
- Chaque job parallèle écrit-il sous un préfixe de répertoire unique lié à
GITHUB_RUN_IDou équivalent ? - Les clés du cache Actions sont-elles liées à la version de build Xcode + fichiers de verrouillage pour éviter des restaurations silencieusement incompatibles ?
- Les tableaux de bord montrent-ils la marge disque par hôte avec alerte avant l'échec d'archivage ?
- Les durées de rétention des artefacts et journaux sont-elles documentées avec la conformité, pas seulement les valeurs par défaut du YAML ?
- Existe-t-il un runbook pour drainer un runner, effacer les espaces de travail et se ré-enregistrer sans fuite de jetons d'enregistrement ?
Pourquoi la classe Mac mini reste pertinente pour les pools de runners
Caches et règles de concurrence n'aident que si l'hôte reste en ligne. Les boîtiers Mac mini Apple Silicon combinent une bande passante mémoire élevée avec une consommation au repos très faible — autour de 4 W en veille active sur les générations M récentes — ce qui compte lorsque les runners restent tièdes entre deux fusions. macOS sur matériel Apple évite la pile fragile d'installations macOS non officielles sur PC génériques, et Gatekeeper plus SIP offrent aux équipes sécurité un récit plus net pour les comptes de build sans surveillance qu'avec de nombreuses flottes Windows. L'architecture mémoire unifiée limite aussi les à-coups des grosses compilations incrémentales par rapport à des PC compacts GPU dédié + DRAM étroite.
Si vous dimensionnez la prochaine vague de capacité, partez des métriques de files et des courbes de croissance disque — puis ajoutez des nœuds plutôt que de surpayer des cœurs au repos. Lorsque vous avez besoin de Mac cloud dédiés pour absorber les pics sans cycle d'achat, le Mac mini M4 reste une ancre SKU solide : associez-le aux politiques de cache et de nettoyage ci-dessus, et la montée en charge horizontale devient prévisible. Lorsque vous êtes prêt à provisionner des machines dédiées à la demande, ouvrez la page d'accueil Macstripe pour comparer régions et modèles selon votre latence et vos contraintes de conformité.
