Sommaire
Objectifs du pool partagé et risques
Le pool vise retours PR rapides, releases reproductibles et équité sur le Mac distant. Le Runner auto-hébergé planifie les jobs mais n’isole pas tout : sans règles, CPU, RAM, disque, Simulateur et trousseau saturent et la CI d’équipe semble « bloquée » sans diagnostic clair.
Limites typiques à adresser :
- Concurrence implicite : plusieurs workflows lourds sur un seul hôte sans plafond mesurable.
- Routage fragile : labels ambigus qui envoient une release sur une mauvaise variante Xcode.
- Coût caché ops : débogage des conflits Simulateur, ports ou certificats sans runbook ni propriétaire.
Quand scinder les files (checklist décision)
- Scinder si deux lignes de produit exigent des versions macOS ou Xcode différentes : pools et routage par labels distincts.
- Scinder lorsque sessions VNC interactives et CI lourde se chevauchent : dédier un nœud ou des créneaux horaires.
- Scinder pour garantir la capacité release : labels du type
ci-releasederrière des Runners qui n’acceptent pas le bruit des PR. - Garder une file unique tant qu’une seule baseline Xcode suffit et que la parallélisation reste faible — structurez après mesure des conflits.
Matrice comparative du routage par labels
Le routage par labels choisit quel Runner auto-hébergé peut prendre un job. Des noms flous provoquent des erreurs de ciblage, du matériel inactif ou pire, des builds sur la mauvaise machine de confiance.
| Schéma de routage | Cas d’usage | Compromis |
|---|---|---|
| Pool large | macos, arm64 — flotte homogène, une épingle Xcode. |
Bonne utilisation ; difficile de réserver de la capacité release. |
| Périmètre toolchain | xcode-16-2, swift-6 — comportement compilateur figé. |
Plus de Runners à suivre ; calendrier d’upgrade synchronisé avec les labels. |
| Niveaux SLA | ci-pr vs ci-release. |
Exige assez de machines par niveau ; un niveau vide bloque les jobs. |
| Tranche équipe | team-mobile, refacturation ou blast radius. |
Utilisation parfois basse ; surcharge opérationnelle. |
Convention de nommage : os + arch + xcode-M-m ; suffixes ci-pr, ci-release, experimental (pas de réutilisation cross-Xcode sans migration). Gardez self-hosted et publiez la liste officielle dans le wiki et les README.
Stratégie de file d’attente et de verrous
La file concurrente mélange sémantique GitHub (combien de jobs le Runner accepte), physique (cœurs, SSD, Simulateur) et conventions (mutex signature). Partez conservateur ; augmentez seulement si CPU soutenu, RAM libre et latence disque le permettent.
| Politique | Seuil de départ | Note |
|---|---|---|
| Plafond concurrence (compile / archive lourde) | 1 job actif par Mac | Ajoutez un nœud avant archives parallèles soutenues sur une seule machine. |
| Plafond tâches légères | Jusqu’à 2 si CPU < ~75 % et RAM libre > ~8 Go | Coupler à concurrency: pour annuler les builds PR obsolètes. |
| Profondeur globale de file | Échec ou report au-delà de ~20 jobs en attente par pool | Évite les files silencieuses multi-heures ; préférez une alerte explicite. |
| Verrou / mutex | Une séquence signature ou notarisation à la fois par trousseau | Verrou fichier, Redis ou action approuvée pour les étapes non réentrantes. |
Détails FIFO, quotas et conflits : FAQ pool Mac partagé.
Étapes opérationnelles
- Inventorier workflows et labels ; retirer l’orphelin.
- Plafonner la concurrence dans les YAML et nommer un propriétaire des changements.
- Profondeur max de file (~20) avec échec explicite au-delà.
- Verrou sur signature / notarisation partagée.
- Nettoyage DerivedData post-release ; revue trimestrielle SLA, échecs, disque.
Droits et isolation : points clés
Évitez artefacts world-readable, profils effacés par erreur et trousseau de session unique : comptes ou répertoires CI dédiés, trousseaux d’automation, chemins partagés documentés (setgid / ACL).
Seuils disque : purge DerivedData / caches quand l’espace libre < 15–20 % ou < 40 Go (le plus contraignant) ; cap caches projet 30–80 Go. Pas de rm -rf aveugle. Voir FAQ SSH/VNC et guide isolation.
Supervision et alertes
Signaux minimum : battement Runner, délai file, saturation CPU/RAM/disque, échecs trousseau. Alerte si attente PR > SLO (souvent 10–20 min) ou disque sous les seuils ci-dessus. CI instable : croiser SSH et maintenance — FAQ stabilité, checklist reconnexion.
FAQ
- Les labels remplacent-ils une file métier ?
- Non : filtres Runners seulement. Priorités :
concurrency, orchestrateur ou nœuds séparés. - Plusieurs Runners sur un Mac M4 ?
- Build lourd : un Runner par machine par défaut ; plusieurs processus = plus de contention.
- Multi-nœuds ou offre équipe ?
- SLA rompus, signature conflictuelle, maintenance qui bloque tous les dépôts : architecture à scaler, pas un simple curseur.
Multi-nœuds et offres équipe : séparez PR, release et environnements Xcode
Un seul Mac distant atteint vite ses limites pour le routage par labels et la file concurrente : les offres multi-nœuds / équipe séparent PR, release et Xcode. Aide (SSH/VNC), accueil, blog, achat / location. Lisez aussi SSH vs VNC, stabilité, Runner vs Mac loué.