2026 Trunk & Merge Queue on Multi-Region Physical Macs: How to Flatten Orchestration Long-Tails and Lock Storms—Queue Depth, Label Routing & Artifact Affinity Threshold Matrices (Copy-Paste GitHub Actions merge-group Snippet + FAQ)

Three decision matrices: queue depth, label routing, artifact affinity

Matrix A: When to tighten Merge Queue / concurrency groups

Matrix B: Label routing (multi-region physical Mac)

Matrix C: Artifact affinity (thresholded)

Use all three together: queue depth answers who runs first, labels answer where it runs, affinity answers what moves before it runs—drop one corner and you get “green merges” that still ship slowly.

Seven-step runbook

1. Freeze baselines: Split timings for PR checks, merge_group, and pushes to default; track per-region runner queue depth and retry rate.
2. SLA merge_group: Target duration below the business max for “time waiting to merge,” with artifact download share called out separately.
3. Tighten concurrency: Use concurrency or “one heavy job per runner” for shared mutable resources to remove false negatives first.
4. Add regional labels: Pin default-branch validation to the same region as artifacts and dependency mirrors; cross-border read-only acceleration only.
5. Calibrate artifact paths: Large intermediates: same-region generate–reference–verify digest; avoid repeated full uploads inside merge_group.
6. Game-day faults: Drain one region or inject throttling; confirm queue fallback does not violate signing jurisdiction (document RTO if the authority region cannot move).
7. Write thresholds down: Capture queue depth / RTT / artifact size in an ADR so scaling does not erase informal rules.

Cite-ready thresholds (ADR-friendly)

• Merge Queue wait P95 > ~2× one merge_group validation → tune concurrency and split jobs before buying hardware.
• Cross-border artifact pull RTT P95 > ~80–120ms with single download > ~5GB → default to same-region build+verify alignment.
• On self-hosted physical Macs, keep one heavy UI job per runner inside a concurrency group to avoid simulator fights.
• Short-term queue reformation failure rate > ~5% → inspect branch protection and drift, not higher retries.

Copy-paste GitHub Actions merge_group snippet

Minimal merge_group trigger alongside pull_request, plus a concurrency key to reduce lock storms on self-hosted runners. Replace runs-on labels and region names for your fleet.

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 / your merge validation commands

Notes: merge_group must check out the same ref as the queue’s temporary merge commit; tune the concurrency key so PR and merge-queue runs do not cancel the wrong work (split workflows if needed). GitHub’s merge_group semantics evolve—validate end-to-end in a throwaway repo before production.

FAQ

Can merge_group and pull_request share one job definition?

Yes for steps, but keep explicit if/ref handling—queue reformation is where wrong SHAs produce “random red.”

Should physical Mac pools mix with GitHub-hosted runners?

Possible, but labels must be mutually exclusive and documented; unify artifact and cache path contracts so one concurrency group does not span runner classes with different filesystem layouts.

Lock storm: drain the queue or kill jobs first?

Reduce parallelism and shrink lock grain first; draining the queue drops ordered merge intent and is usually reserved for control-plane incidents.

Run the queue reliably on Mac mini

Trunk and Merge Queue push merge correctness into CI, while physical Mac runners carry real Xcode and simulator load—together, stability and IO consistency matter more than peak GHz. Apple Silicon Mac mini pairs unified memory bandwidth with roughly ~4W idle power, so regional runners can stay warm overnight without the thermal swings that force you to keep retuning lock TTLs on many x86 towers.

macOS ships the same roots as your laptops, shrinking “passes locally, flakes in CI” gaps; Gatekeeper, SIP, and FileVault make session and disk state easier to explain under audit than a typical Windows build farm. Colocate runners with artifacts and mirrors, then use labels and concurrency to enforce lock boundaries—if you want merge_group validation on hardware that is quiet, efficient, and predictable, Mac mini M4 remains one of the strongest price–performance starting points.

If you are ready to move from “merge_group runs sometimes” to “queue depth and affinity thresholds you can trust,” pick up a Mac mini now and run this matrix on real silicon instead of fighting cloud quotas alone.