Kleine Teams, ein geteilter Remote-Mac: Merge Queue, Runner-Labels, Concurrency & flock/timeout
Die GitHub-Merge Queue erzeugt einen vorgeordneten Integrationsstrom: statt sofort zu mergen, werden Änderungen in eine Warteschlange aufgenommen, mit dem Zielbranch vorab zusammengeführt und erst nach erfolgreichen Checks integriert. Das entlastet den menschlichen Review, ersetzt aber keine Kapazitätsplanung auf dem Builder: mehrere Queue-Einträge können weiterhin gleichzeitig Workflow-Jobs starten, die um Xcode, Simulator, Artefakte und Signing konkurrieren. Für kleine Teams auf einem gemieteten Mac-Pool ist deshalb die Kombination aus Queue-Disziplin (GitHub) und Host-Disziplin (Mac) entscheidend.
Parallel dazu sollten Sie die Runner-Routing- und Warteschlangen-Matrix kennen: Labels sind nur ein Filter, keine faire Scheduler-Schicht. Ergänzend helfen Queue- und Lock-FAQs sowie flock auf gemeinsamen Build-Pfaden, wenn Shell-Skripte und CI-Steps dieselben Verzeichnisse anfassen. Für verteilte Zusammenarbeit über mehrere Knoten lohnt der Blick in OpenClaw-Mehrknoten-Kollaboration auf Mac-Mesh und die Codespaces-SSH-vs.-Direkt-Mac-Matrix für Pairing und Sprünge.
Entscheidungsmatrix: Merge Queue, Runner-Pool und Host-Sperre
Nutzen Sie die Tabelle, um zu klären, wo Serialisierung stattfinden soll. Ziel ist, dass weder die Queue „leerläuft“ (weil der Runner blockiert), noch der Runner überbucht ist (weil GitHub parallel mehrere schwere Jobs schedult).
| Szenario | Merge Queue | Runner-Labels | Concurrency / flock | Präemption / Eskalation |
|---|---|---|---|---|
| Ein Repo, ein Release-Branch, schwere Xcode-Archive | Ja – serialisiert Merge-Reihenfolge auf dem Branch | mac-release nur auf einem Host |
concurrency: group: release, cancel-in-progress: false + optional flock auf Artefakt-Pfad |
Kein Cancel-in-progress für Releases; bei Timeout zweiten Mac-Knoten aus Preis-/Paketseite nachziehen |
| Mehrere Repos zeigen auf denselben Mac | Pro Repo konfigurierbar; reduziert „Merge-Rennen“, nicht SSD-Wettbewerb | Getrennte Labels mac-ci / mac-nightly oder Repo-Präfix im Namen |
Globale Gruppe org-shared-mac mit niedrigem Parallelgrad; flock für gemeinsame Cache-Verzeichnisse |
Nightly darf PR-Jobs verdrängen nur mit expliziter Policy und kürzerem timeout |
| Monorepo, viele parallele PR-Checks | Merge Queue sinnvoll bei hoher Merge-Frequenz | mac-pr mit Matrix; schwere Jobs auf mac-heavy umleiten |
Concurrency pro Pfad/Team; flock nur für echte exklusive Ressourcen (z. B. ein Simulator-Profil) | cancel-in-progress: true für veraltete PR-Commits; nicht für Queue-Merge-Builds ohne Ersatz |
| Externe Scheduler (Cron/Nomad) + Actions | Queue schützt Branch; externe Jobs brauchen eigene Slot-Regel | Label mac-actions vs. mac-batch |
flock-Datei pro Ressource; siehe Nomad vs. Cron-Matrix | Batch verliert gegenüber interaktiven PR-Jobs nach SLA-Tabelle (manuell dokumentieren) |
Parameterliste (Queue-Tiefe, Labels, Sperren, Timeouts, Präemption)
Die folgenden Richtwerte sind Startpunkte für einen gemeinsamen M4/M3-Builder mit 16–64 GB RAM; passen Sie sie an Ihre Xcode-Stufen, DerivedData-Größe und parallele Simulator-Anzahl an. Dokumentieren Sie die Werte im Runbook – idealerweise verlinkt aus dem Hilfezentrum (lesbar ohne Login).
| Parameter | Empfehlung (Start) | Hinweis |
|---|---|---|
| Merge-Queue-Tiefe / parallele „speculative“ Builds | 2–4 parallele Einträge, wenn ein Host maximal 1–2 schwere Xcode-Jobs verträgt | Wenn die Queue ständig „wartet“, obwohl CPU müßig ist, fehlt oft I/O oder ein zweites Label/Host – nicht „mehr Queue“. |
Runner-labels |
self-hosted + Umgebung (macos, Region) + Rolle (ci, release) |
Keine generischen mac-Labels auf mehreren Heterogen-Hardware ohne Versionstag – sonst wandert ein ARM-Job auf den falschen Chip. |
concurrency-Gruppe |
Eine globale Gruppe pro physischem Host für schwere Jobs (physical-mac-01-heavy) |
Feinere Gruppen pro Repo nur, wenn Sie echte Parallelität mit separaten Ressourcen haben (z. B. zweite SSD). |
flock + timeout (Shell) |
flock -w 300 /var/tmp/meshmac-build.lock mit Hard-Cap z. B. 45 min Gesamtjob |
-w verhindert endloses Warten; kombinieren mit Actions-timeout-minutes auf Job-Ebene. |
| Actions-Job-Timeout | PR: 30–60 min; Release-Archive: 90–120 min | Kürzere Timeouts für Matrix-Jobs mit Retry; längere nur mit exklusiver Concurrency-Gruppe. |
| Präemption | PR: cancel-in-progress: true; Merge-Queue-Merge-Builds: meist false |
Nightly darf PR nur abbrechen, wenn Rework billig ist – sonst entstehen flaky „roten“ Hauptlinien. |
Wechselwirkungen: GitHub-Warteschlange vs. Host-Warteschlange
Ein häufiges Missverständnis: Sobald die Merge Queue aktiv ist, „regelt GitHub alles“. Tatsächlich koordiniert die Queue vor allem Integrationsversuche auf dem geschützten Branch und reduziert manuelles Nachziehen bei konkurrierenden PRs. Die Runner-Auswahl bleibt jedoch ein separates Problem: ein Workflow, der auf runs-on: [self-hosted, mac-ci] zeigt, kann weiterhin gleichzeitig mit anderen Repos oder Workflows starten, die dieselben Labels tragen. Ohne zusätzliche concurrency-Grenze oder zweiten physischen Host entsteht so ein logischer Parallelitätsfehler: die Queue ist „fair“, der Mac aber überbucht.
Um das sichtbar zu machen, empfiehlt sich ein schlankes Dashboard oder zumindest strukturierte Logs: pro Job Wartezeit bis Runner-Zuweisung, Dauer der flock-Wartezeit und I/O-Wartezeit (z. B. über einfache Timestamps vor/nach DerivedData-Clean). Steigt die Runner-Wartezeit ohne dass die Merge-Queue lang ist, stimmt Label-Kapazität und Host-Zahl nicht mit der echten Parallelität überein – dann nützen feinere Timeouts nur begrenzt. Steigt dagegen die Queue-Latenz bei mäßiger Runner-Auslastung, prüfen Sie required checks, wiederholte Retries oder externe Webhooks, die zusätzliche Jobs triggern.
Schließlich sollten Präemptionsregeln schriftlich fixiert werden: wer darf welche Jobs abbrechen, in welcher Reihenfolge Nightly- oder Datenaufbereitungsjobs laufen, und wie lange ein Merge-Queue-Build warten darf, bevor das Team manuell eingreift. Diese Policy ist Teil der Kollaborationskultur – technisch flankiert durch cancel-in-progress, organisatorisch flankiert durch klare On-Call- und Runbook-Links. So bleibt der geteilte Remote-Mac ein Produktivmittel statt einer permanenten Störquelle zwischen Entwicklern und CI.
Praxis: Reihenfolge beim Rollout
- Zielbranch und Merge-Policy festlegen (required checks, Anzahl paralleler Spekulationen).
- Runner-Labels so benennen, dass Merge-Queue-Workflows und normale PR-Workflows klar getrennt umleiten können.
- Concurrency für schwere Schritte an den physischen Host koppeln – nicht nur an den Branchnamen.
- flock für Pfade, die GitHub nicht serialisiert (gemeinsamer Cache, Bundle-Install in ein Verzeichnis).
- Metriken: Queue-Wartezeit, Job-Wartezeit auf „Runner pickup“, SSD-Auslastung – wenn zwei Kurven divergieren, skalieren Sie Runner/Knoten statt Parameter zu drehen.
Wer Worktrees oder parallele Locks im Monorepo nutzt, sollte die Git-Worktree- und Lockfile-Matrix mit einbeziehen; für gemeinsame MLX-/ML-Experimente eignet sich ergänzend der Überblick Team-Kollaboration M4 MLX-Pool.
Kurz-FAQ
- Ersetzt die Merge Queue einen Scheduler?
- Nein. Sie ordnet Branch-Integrationen; parallele Jobs auf demselben Host steuern Sie mit Labels,
concurrency, ggf. externer Queue oder zweitem Knoten. - Warum hängen Jobs trotz freier CPU?
- Typisch: I/O (DerivedData), Simulator-Exklusivität oder ein
flock, das länger wartet als erwartet – prüfen Sie-wund konkurrierende Cron-Jobs.
Knoten skalieren, Queue entspannen
Wenn Merge Queue und Runner-Labels trotz Sperren aneinander vorbeilaufen, ist meist die physische Parallelität zu niedrig. Erweitern Sie den Pool: auf der Preise-/Kaufseite (Pakete transparent, ohne Login einsehbar) finden Sie zusätzliche Mac-Mini-Optionen; die Startseite fasst Mehrknoten- und Team-Szenarien zusammen. Im Hilfezentrum lesen Sie SSH-, VNC- und Einrichtungsartikel ebenfalls ohne Anmeldung. Vertiefung im Blog über die verlinkten Kollaborations- und Runner-Guides.
Fazit: Die Merge Queue stabilisiert die Integrationsreihenfolge auf GitHub; Labels, Concurrency, flock und Timeouts stabilisieren die Ausführung auf dem geteilten Mac. Steigen parallele Anforderungen dauerhaft, lohnt sich der nächste Schritt weniger in Feintuning-Parametern als in zusätzlichen Knoten oder einem höheren Team-Paket – damit Queue, Actions und Entwickler nicht um dieselbe Maschine ringen.