Double file d'attente · Routage des labels · Concurrency · Observabilité de la voie merge
Sur plusieurs Mac distants loués avec runners self-hosted, l'erreur fréquente est de croire que la Merge Queue orchestre aussi la capacité machine : la file GitHub ordonne les changements et les garde-fous vers la branche par défaut, mais le backlog runner reste dicté par labels et groupes de concurrence. Cet article sépare les deux files avec un tableau de partage du plan de contrôle, propose le routage ci-pr / ci-merge / ci-release, les règles concurrency et cancel-in-progress, et des critères p95 pour décider entre ajouter des Mac ou régler GitHub en premier ; liens vers pool de build partagé, mutex de sièges et orchestration Mac Mesh.
La Merge Queue protège l'intégrité de la branche par défaut : elle enchaîne les lots de vérifications avant intégration ; elle ne garantit pas des CPU libres sur vos runners Mac distants. Si PR et merge partagent les mêmes labels runs-on, GitHub peut avancer les fusions pendant que les runners sont saturés par des jobs PR optionnels.
Confusion des deux files : interpréter le \"Queued\" d'Actions comme si la Merge Queue boostait toujours les jobs merge.
Labels mélangés : un ci vague empile nightly, PR et merge sur les mêmes runners.
Mauvaises annulations : cancel-in-progress: true sur la voie merge comme pour les PR déchiquette les lots.
Collisions de concurrence : plusieurs dépôts partagent la même chaîne concurrency et s'annulent.
Observabilité faible : on ne sépare pas attente merge queue et runner occupé.
Décalage de lease mesh : la voie merge veut une occupation stable mais sans seuils de bail.
Astuce : si vous comparez encore portable et distant plutôt que le plan de contrôle CI, lisez d'abord édition locale légère vs builds distants lourds.
Le tableau ci-dessous sert aux revues ; faire les deux n'a de sens que si la capacité runner est honnête, pas du théâtre de labels.
| Plan de contrôle | GitHub Merge Queue | Backlog runner (file machines) |
|---|---|---|
| Couvre | Ordre vers la branche par défaut, lots merge, sémantique des checks requis | Quel Mac exécute quel job workflow quand |
| Ne couvre pas | Combien de cœurs perf sont libres sur votre M4 | Si une PR doit logiquement passer devant |
| Échec typique | Lots timeout malgré une logique saine mais manque de CPU | Jobs merge longtemps en queue alors que la file est courte |
| Premier levier | Resserrez checks requis et hypothèses de lots | Coupez les labels runs-on, ajoutez runners ou sièges réservés |
Des merges fluides dépendent d'une capacité runner honnêtement réservée au merge, pas du seul interrupteur Merge Queue.
self-hosted + macOS + ci-pr + pin de toolchain (ex. xcode-16-2).ci-merge servi par au moins un runner Mac distant.ci-release séparé du merge pour ne pas affamer le trunk.Ces étapes complètent le guide SSH du pool partagé : là on joint le runner ; ici on définit qui possède quelle timeline CPU.
Inventorier les checks requis : listez ce qui bloque réellement la branche par défaut, durées, ce qui peut monter en PR.
Fractionner runs-on : attribuez ci-merge aux workflows ou jobs merge-only ; une machine peut porter plusieurs labels mais réservez des créneaux ou des nœuds dédiés.
Auditer concurrency : PR avec cancel-in-progress: true ; merge/release avec cancel-in-progress: false ou clés plus étroites.
Nommer les groupes concurrency : inclure dépôt, workflow et suffixe d'environnement.
Instrumenter : séparer sur le tableau de bord attente merge queue et minutes occupées runner.
Revue de barrière : deux fois par semaine file courte mais merge longtemps en queue ? changez d'abord la topologie runner.
concurrency:
group: ${{ github.workflow }}-${{ github.ref }}-${{ github.event_name }}
cancel-in-progress: ${{ github.event_name == 'pull_request' }}
jobs:
merge-gate:
runs-on: [self-hosted, macOS, ci-merge, xcode-16-2]
timeout-minutes: 45
steps:
- run: echo "merge lane only"
Les motifs viennent de post-mortems courants ; remplacez les seuils par vos données. Ne mélangez pas les deux files d'attente sur un même graphique.
| Signal | Cause probable | Premier geste |
|---|---|---|
| Longue merge queue, runners inactifs | Checks requis ou politique de lots trop stricts | Revoir le graphe des checks et les hypothèses de parallélisme |
| File courte, job merge longtemps en queue | Routage des labels ou trop peu de runners | Séparer ci-merge, ajouter nœuds ou sièges |
| Lots infra en échec | Timeouts, disque, trousseau, réseau | Comparer journaux runner et checklist gouvernance des signatures |
| PR rapides, merges lents | PR et merge se disputent les mêmes labels | Fractionner runs-on et réduire jobs PR optionnels |
Attention : du matériel plus rapide sans séparation des labels décale souvent la famine vers les nuits de release ; à terme il faut des noms de capacité distincts.
Les plages ci-dessous sont des ancrages typiques pour équipes réparties ; reliez vos champs SQL ou API au runbook interne.
ci-merge avec busy minutes au-dessus de 85 % en journée, déplacez nightly vers le pool ci-pr.concurrency partagée avec les PR.| Taille d'équipe | Cadence merge trunk | Premier geste recommandé |
|---|---|---|
| Petite | Plusieurs fois par jour | Un runner ci-merge dédié + checks requis stricts |
| Moyenne | Lots continus | Runners multi-régions + pool release explicite |
| Plateforme | Pool partagé multi-dépôts | Standards de labels d'org + tableau des coûts queue vs runner |
Un portable comme runner temporaire apporte veille thermique et login interactif peu auditable ; des Mac en colocation ajoutent achat et câblage. Peu contractuel pour un SLO de merge vérifiable.
Pour des pools Mac distants où iOS CI/CD et jobs longs d'agents IA coexistent, la location cloud de Mac Mini VpsMesh est souvent le meilleur choix : étendez la flotte par région et SKU, placez merge, release et bruit quotidien sur des nœuds nommés, mettez disponibilité et politique de sièges dans des engagements ops, pas dans Slack.
Pas forcément une machine physique dédiée, mais il faut honnêtement séparer labels et concurrence sinon le bruit PR affame les vérifications merge. Mieux : lier ci-merge à des sièges fixes ou nœuds dédiés. Montée en charge : page Tarifs et page Commander.
Les pushes PR rendent les anciens checks obsolètes ; annuler trop de lots merge augmente le risque de changements fusionnés sans boucle d'automatisation fermée. Encodez la politique dans le YAML et reliez les runbooks depuis le Centre d'aide.
D'abord pool de build partagé pour SSH et enregistrement runner, puis cet article pour scinder la voie merge ; verrous de sièges dans l'article mutex TTL.