Zwei-Warteschlangen-Denken · Label-Routing · Concurrency · Merge-Spur beobachtbar
Wenn Sie Self-hosted Runner auf mehreren gemieteten Remote-Macs betreiben, führt ein häufiges Missverständnis dazu, anzunehmen, die Merge Queue plane auch Maschinenkapazität: Die Merge Queue ordnet Änderungen und Sicherheitsgates in den Default-Branch, aber das Runner-Backlog bestimmen weiterhin Labels und Concurrency-Gruppen. Dieser Artikel trennt die beiden Warteschlangen mit einer Kontrollflächen-Matrix, empfiehlt Routing mit ci-pr / ci-merge / ci-release, erklärt Regeln für Concurrency und cancel-in-progress und wann p95-Wartezeiten eher Mac-Kapazität oder GitHub-Konfiguration verlangen; verlinkt werden gemeinsamer Build-Pool, Seat-Mutex und Mac-Mesh-Orchestrierung.
Die Merge Queue schützt die Integrität des Default-Branches: sie bündelt Checks vor der Integration; sie garantiert keine freien CPUs auf Ihren Remote-Mac-Runnern. Teilen PR- und Merge-Checks dieselben runs-on-Labels, kann GitHub Merges voranbringen, während Runner mit optionalen PR-Jobs voll sind.
Zwei-Queue-Verwechslung: Actions \"Queued\" wird so gelesen, als würde die Merge Queue Merge-Jobs automatisch priorisieren.
Label-Mix: Ein vages ci-Label stapelt Nightly, PR und Merge auf denselben Runnern.
Falsche Abbrüche: cancel-in-progress: true auf Merge-Spuren wie bei PRs reißt Batches wiederholt ab.
Concurrency-Kollisionen: Mehrere Repos oder Workflows teilen dieselbe concurrency-Zeichenkette und brechen sich gegenseitig ab.
Fehlende Observability: Merge-Queue-Wartezeit und Runner-Auslastung werden nicht getrennt; Kapazitätsgespräche ohne Daten.
Mesh-Lease-Mismatch: Merge-Spuren brauchen stabile Knotenbelegung, aber Lease-Schwellen fehlen.
Hinweis: Wenn Sie noch Laptop-vs.-Remote vergleichen statt CI-Kontrollflächen, lesen Sie zuerst lokales Leichteditieren vs. Remote-Build-Schwellen.
Die Matrix unten ist für Review-Meetings; beides zu tun ist nur dann sinnvoll, wenn die Runner-Kapazität ehrlich ist, nicht Label-Theater.
| Kontrollfläche | GitHub Merge Queue | Runner-Backlog (Maschinenqueue) |
|---|---|---|
| Zuständig für | Reihenfolge in den Default-Branch, Merge-Batches, Semantik der Pflicht-Checks | Welcher Mac welchen Workflow-Job wann ausführt |
| Nicht zuständig für | Wie viele Performance-Kerne auf Ihrem M4 frei sind | Ob ein PR logisch vordringen sollte |
| Typischer Fehler | Batches laufen wegen Rechenmangel trotz korrekter Logik aus | Merge-Jobs bleiben queued, die Queue ist kurz |
| Erster Hebel | Pflicht-Checks und Batch-Annahmen straffen | runs-on-Labels teilen, Runner ergänzen oder Plätze reservieren |
Glättende Merges hängen an ehrlich reservierter Runner-Kapazität für Merge, nicht am Merge-Queue-Schalter allein.
self-hosted + macOS + ci-pr + Toolchain-Pin (z. B. xcode-16-2).ci-merge, bedient von mindestens einem Remote-Mac-Runner.ci-release getrennt von Merge, damit große Release-Jobs den Trunk nicht aushungern.Die Schritte ergänzen den SSH-Leitfaden zum gemeinsamen Pool: dort klar, ob der Runner erreichbar ist; hier, wer welche CPU-Timeline besitzt.
Pflicht-Checks inventarisieren: Erfassen Sie tabellarisch, was den Default-Branch blockiert, mit Dauer und was früher in PR kann.
runs-on teilen: Merge-Workflows oder -Jobs erhalten ci-merge; ein physischer Mac darf viele Labels, aber Fenster reservieren oder dedizierte Knoten.
Concurrency prüfen: PR nutzt cancel-in-progress: true; Merge/Release cancel-in-progress: false oder engere Gruppen.
Concurrency-Gruppen benennen: Repo, Workflow und Umgebung anhängen, um Kollisionen zu vermeiden.
Instrumentieren: Trennen Sie Merge-Queue-Wartezeit und Runner-Busy-Minuten auf dem Teamboard.
Gate-Review: Zwei Mal pro Woche kurze Queue aber lange Merge-Queue? Zuerst Runner-Topologie, dann GitHub-Parallelität.
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"
Die Muster stammen aus typischen Postmortems; ersetzen Sie Schwellen durch Ihre Daten. Wichtig: beide Wartearten nicht auf derselben Achse.
| Signal | Wahrscheinliche Ursache | Erste Maßnahme |
|---|---|---|
| Lange Merge-Queue, idle Runner | Pflicht-Checks oder Batch-Policy zu streng | Checks-Grafik und Parallelitätsannahmen prüfen |
| Kurze Queue, Merge-Job lange queued | Label-Routing oder zu wenige Runner | ci-merge splitten, Knoten oder Plätze hinzufügen |
| Batches scheitern als Infra | Timeouts, Disk, Keychain, Netz | Runner-Logs mit Signing-Governance abgleichen |
| Schnelle PRs, langsame Merges | PR und Merge teilen Labels | runs-on trennen, optionale PR-Jobs kürzen |
Achtung: Schnellere Hardware ohne Label-Trennung verschiebt Hunger oft nur in Release-Nächte; langfristig braucht es getrennte Kapazitätsnamen.
Die Bandbreiten sind typische Anker für verteilte Teams; hängen Sie Ihre SQL- oder API-Felder ins interne Runbook.
ci-merge-Runnern mit über 85 % Busy-Minuten zur Geschäftszeit → Nightlys in den ci-pr-Pool.concurrency-Politik mit PR.| Teamgröße | Trunk-Merge-Takt | Erster Schritt |
|---|---|---|
| Klein | Mehrfach täglich | Ein dedizierter ci-merge-Runner + strenge Pflicht-Checks |
| Mittel | Kontinuierliche Batches | Multi-Region-Runner + expliziter Release-Pool |
| Plattform | Geteilter Multi-Repo-Pool | Org-Label-Standards + Kostenboard Queue vs Runner |
Ein Notebook als temporärer Runner bringt Sleep, Thermik und nicht auditierbare interaktive Logins; Colo-Macs bringen Beschaffung und Verkabelung. Beides trägt selten einen reviewbaren Merge-SLO-Vertrag.
Für Remote-Mac-Pools mit iOS CI/CD und langen AI-Agent-Jobs sind VpsMesh Mac Mini Cloud-Mieten meist die bessere Wahl: Runner-Fleet nach Region und SKU skalieren, Merge, Release und Alltagslärm auf benannten Knoten legen, Verfügbarkeit und Seat-Policy in Ops-Verträge statt Slack.
Nicht zwingend ein eigener Rechner, aber Labels und Concurrency müssen ehrlich getrennt sein; sonst verhungern Merge-Checks an PR-Rauschen. ci-merge sollte festen Plätzen oder dedizierten Knoten folgen. Skalierung: Preisseite und Bestellseite.
PR-Commits machen alte Checks obsolet; wiederholtes Abbrechen von Merge-Batches erhöht das Risiko gemergter Änderungen ohne geschlossene Automatisierung. Politik in YAML festhalten und Team-Runbooks aus dem Hilfezentrum verlinken.
Zuerst gemeinsamer Build-Pool für SSH und Runner-Registrierung, dann diesen Artikel für Merge-Spuren; Seat-Locks im Mutex-TTL-Artikel.