Sommaire
Deux files, une machine
La merge queue répond : « quelle PR intègre la branche par défaut ensuite, et le dernier commit tient-il encore après rebase ? » Elle réduit le décalage de fusion et les troncs cassés au niveau Git. Les labels Runner répondent autrement : « quel Mac distant peut exécuter ce job ? » Les labels ne créent ni équité inter-dépôts ni priorité métier — ils filtrent les hôtes éligibles.
Quand les deux mécanismes coexistent, la latence perçue est souvent dominée par le pool : archives Xcode, simulateurs, signature. La file merge peut sembler saine alors que les jobs s’accumulent derrière un sous-ensemble d’étiquettes. D’où l’intérêt des guides Codespaces (transfert SSH) vs nœud direct et du playbook collaboration multi-nœuds : vous dimensionnez pour humains et CI sur la même capacité.
Documentez ensemble politique de tronc (merge queue, checks requis) et politique matérielle (labels, pools, préemption). L’accueil Meshmac résume le service ; la page achat / forfaits est consultable sans compte pour comparer nœuds et offres avant d’engager des runners dédiés.
Matrice : merge queue d’abord, labels d’abord, ou les deux
Choisissez un plan de contrôle principal. Les équipes matures combinent en général merge queue (tronc) et routage par labels (builders) — la ligne « les deux » est le défaut recommandé dès que vous livrez au moins hebdomadairement sur la branche par défaut.
| Approche | Pertinent quand | Risque principal | Atténuation Mac partagé |
|---|---|---|---|
| Merge queue d’abord | Fort débit de fusion, tronc strict, nombreux contributeurs sur une branche par défaut unique. | Cycles CI supplémentaires par entrée ; impression de « double attente » si les Runners sont saturés. | Plafonner les builds issus de la file, aligner les checks requis, router vers des labels ci-merge sur hôtes réservés ou peu chargés. |
| Labels d’abord | Peu de fusions, plusieurs broches Xcode/SDK, ou flotte hétérogène. | Le tronc peut encore casser sur des conflits logiques que la merge queue aurait détectés. | Activer la merge queue sur la branche par défaut tout en gardant les labels pour l’isolation toolchain. |
| Les deux (échelle) | Pool Mac distant servant PR et tronc ; releases avec créneaux prévisibles. | Dispersion des politiques — timeouts ou clés concurrency incohérents entre dépôts. |
Convention de nommage des groupes concurrency, doc de préemption, miroir des seuils dans la liste de paramètres ci-dessous. |
| flock sans discipline de file | Un seul mutex lourd (signature) sur une machine. | Masque la parallélisation côté GitHub ; verrou bloqué = workflows sans lien en attente. | Coupler flock à des timeouts muraux et alertes ; préférer des nœuds séparés avant sections critiques illimitées. Voir FAQ flock / file et FAQ verrous de file. |
Liste de paramètres (point de départ 2026)
Valeurs indicatives pour petites équipes ; ajustez à votre p95 d’attente, à la taille SSD et au nombre de processus Runner réellement enregistrés sur chaque Mac. L’objectif est une politique honnête : échec explicite plutôt qu’une file silencieuse de plusieurs heures.
| Paramètre | Valeur / règle de départ | Note opérationnelle |
|---|---|---|
| Profondeur de file (pool) | Alerter ou court-circuiter au-delà d’environ 15–25 jobs en attente par pool homogène | Évite les files « fantômes » ; déclenche plutôt scale horizontal ou report explicite. |
| Runner label (routage) | self-hosted + os/arch + xcode-M-m + suffixe ci-pr / ci-merge / ci-release |
Séparez la voie merge queue des PR bruyantes ; documentez la liste officielle dans le wiki. |
| Verrou de concurrence (workflow) | Une clé stable par périmètre : repo:signing, monorepo:ios-archive |
cancel-in-progress: true sur PR ; prudence ou false sur release / merge queue si vous évitez la préemption destructrice. |
| flock / mutex hôte | flock -w 600 (attente max 10 min) autour codesign / notarisation / slot Simulateur |
Toujours avec journalisation du PID et du chemin de verrou ; pas de section critique sans borne temps. |
| timeout shell / job | Étapes lourdes 45–90 min ; passthrough léger 10–20 min ; workflow global cohérent avec timeout-minutes GitHub |
Alignez avec la profondeur merge queue : un timeout trop court multiplique les faux négatifs sur Mac saturé. |
| Préemption | PR : annuler builds obsolètes ; merge queue : file bornée + labels dédiés ; release : pas d’annulation sauf runbook | Publiez la règle ; reliez-la au SLO d’attente (FAQ latence / SLA). |
Composer les politiques sur un Mac mutualisé
Enchaînez : (1) checks requis + merge queue sur le tronc, (2) labels qui séparent PR, entrées de file et release, (3) concurrency pour le bruit des PR, (4) flock pour les étapes hôte non réentrantes, (5) timeouts et alertes qui reflètent la réalité disque/CPU. Si le goulot reste structurel (signature, une seule ligne Xcode, fenêtre de maintenance qui bloque tous les dépôts), augmenter le parallélisme YAML sur un seul SSD aggrave les conflits — voir FAQ pool partagé.
FAQ
- La merge queue remplace-t-elle le routage par labels ?
- Non : tronc vs machine. Combinez merge queue et labels sur pools matures.
- flock si
concurrencyexiste déjà ? - Oui pour les ressources hôte partagées que YAML seul ne verrouille pas (trousseau, simulateur, cache mono-écrivain).
- Préemption silencieuse : premier levier ?
- Clarifier cancel-in-progress par type de branche, puis dimensionner labels
ci-merge; scalez les nœuds si le p95 d’attente reste hors budget.
Scaler : ajoutez des nœuds ou montez de forfait
Quand la merge queue et les labels sont bien réglés mais que le p95 d’attente ou les conflits disque/signatures persistent, la bonne réponse est souvent plus de builders (nœuds dédiés PR / merge / release) ou un forfait équipe plus large — pas un troisième job lourd sur le même SSD. Comparez les offres publiques et multi-nœuds sur la page d’achat Meshmac sans créer de compte ; l’accueil et le centre d’aide restent en lecture libre. Poursuivez sur le blog (TLS, Ansible, load balancing) pour compléter votre matrice 2026.