2026 — Équipes transnationales : Trunk / Merge Queue et Mac physiques multirégions — comment aplatir la longue traîne d'orchestration et les tempêtes de verrous ? Profondeur de file, routage par labels et matrices de seuils d'affinité des artefacts (extrait GitHub Actions merge_group + FAQ)

Trois matrices de décision : profondeur de file, routage par labels, affinité artefacts

Matrice A : quand resserrer Merge Queue / groupes de concurrence

Matrice B : routage par labels (Mac physique multirégion)

Matrice C : affinité des artefacts (par seuils)

Les trois vont ensemble : la profondeur de file répond à qui passe en premier, les labels à où ça s'exécute, l'affinité à ce qui bouge avant l'exécution — en sacrifier un coin donne des « fusions vertes » qui livrent encore lentement.

Runbook en sept étapes

1. Geler les baselines : séparer les durées des checks PR, merge_group et des pushes vers la branche par défaut ; suivre la profondeur de file des runners par région et le taux de relance.
2. SLA merge_group : viser une durée sous le plafond métier pour « temps d'attente avant fusion », en isolant la part due aux téléchargements d'artefacts.
3. Resserrer la concurrence : utiliser concurrency ou « un job lourd par runner » pour les ressources mutables partagées afin d'éliminer d'abord les faux négatifs.
4. Ajouter des labels régionaux : ancrer la validation de la branche par défaut dans la même région que les artefacts et miroirs de dépendances ; accélération transfrontalière en lecture seulement si besoin.
5. Calibrer les chemins d'artefacts : gros intermédiaires : génération–référence–vérification du digest dans la même région ; éviter uploads complets répétés dans merge_group.
6. Jeu d'incident : drainer une région ou injecter de la limitation ; vérifier que le repli de file ne viole pas la juridiction de signature (documenter le RTO si la région d'autorité ne peut pas bouger).
7. Écrire les seuils : consigner profondeur de file / RTT / taille d'artefacts dans une ADR pour que le scale ne fasse pas disparaître les règles informelles.

Seuils prêts à citer (compatibles ADR)

• Attente P95 de la file de fusion > ~2× une validation merge_group → ajuster concurrence et scinder les jobs avant d'acheter du matériel.
• RTT P95 des tirages d'artefacts transfrontaliers > ~80–120 ms avec un seul téléchargement > ~5 Go → aligner par défaut build+vérif dans la même région.
• Sur Mac physiques auto-hébergés, garder un lourd job UI par runner dans un groupe de concurrence pour éviter les conflits de simulateur.
• Taux d'échec de reformation de file à court terme > ~5 % → inspecter protection de branche et dérive, pas davantage de relances.

Extrait GitHub Actions merge_group à copier-coller

Déclencheur minimal merge_group à côté de pull_request, plus une clé de concurrence pour réduire les tempêtes de verrous sur runners auto-hébergés. Remplacez les labels runs-on et les noms de région selon votre parc.

name: ci

on:
  pull_request:
  merge_group:

concurrency:
  group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.run_id }}
  cancel-in-progress: true

jobs:
  validate:
    if: github.event_name == 'merge_group' || github.event_name == 'pull_request'
    runs-on: [self-hosted, macOS, region-apac]
    steps:
      - uses: actions/checkout@v4
        with:
          ref: ${{ github.event.merge_group.head_sha || github.event.pull_request.head.sha }}
      - name: Build and test (merge queue aware)
        run: |
          echo "Running on ${{ github.event_name }} @ ${{ github.sha }}"
          # xcodebuild / swift test / vos commandes de validation merge

Notes : merge_group doit extraire le même ref que le commit de fusion temporaire de la file ; affinez la clé de concurrence pour que les runs PR et file de fusion n'annulent pas le mauvais travail (scinder les workflows si besoin). Les sémantiques merge_group évoluent — validez de bout en bout sur un dépôt jetable avant la prod.

FAQ

merge_group et pull_request peuvent-ils partager une même définition de job ?

Oui pour les étapes, mais gardez un traitement explicite if/ref — la reformation de file est l'endroit où de mauvais SHA donnent du « rouge aléatoire ».

Les pools Mac physiques doivent-ils se mélanger aux runners hébergés par GitHub ?

Possible, mais les labels doivent être exclusifs et documentés ; unifiez le contrat de chemins d'artefacts et de cache pour qu'un groupe de concurrence ne couvre pas des classes de runners aux layouts disques différents.

Tempête de verrous : vider la file ou tuer les jobs d'abord ?

Réduire d'abord le parallélisme et le grain de verrou ; vider la file casse l'intention de fusion ordonnée et se réserve en général aux incidents de plan de contrôle.

Fiabiliser la file sur Mac mini

Le Trunk et la Merge Queue déplacent la correction des fusions vers la CI, tandis que les runners Mac physiques portent la charge réelle Xcode et simulateur — ensemble, la stabilité et la cohérence des E/S priment sur le GHz de crête. Un Mac mini Apple Silicon allie bande passante mémoire unifiée à une consommation d'environ 4 W au repos, ce qui permet de garder des runners régionaux « chauds » la nuit sans les variations thermiques qui vous forcent à retuner les TTL de verrous sur bien des tours x86.

macOS partage les mêmes fondations que les portables de l'équipe, ce qui réduit l'écart « passe en local, flake en CI » ; Gatekeeper, SIP et FileVault rendent l'état de session et de disque plus auditable qu'une ferme Windows typique. Colocalisez runners, artefacts et miroirs, puis imposez labels et concurrence pour tracer les frontières de verrous — si vous voulez des validations merge_group sur du matériel silencieux, prévisible et sobre, le Mac mini M4 reste l'un des meilleurs rapports prix–performance pour démarrer.

Passez du « merge_group tourne parfois » à des seuils de profondeur de file et d'affinité auxquels vous pouvez faire confiance : choisissez un Mac mini dès maintenant et exécutez cette matrice sur du silicium réel plutôt que de vous battre seuls contre les quotas cloud.