Checkout-Strategie ist der leise Multiplikator hinter jeder macOS-Pipeline: Derselbe Mac mini M4 wirkt mit git worktree «schnell genug» oder «mysteriös flaky», wenn DerivedData zwischen Jobs leckt. 2026 reduzieren Teams, die eine explizite Worktree-vs.-Clean-Clone-Politik veröffentlichen, Wartezeit und Audit-Risiko. Dieser Leitfaden liefert zwei Matrizen, numerische Disk-Budgets, acht Rollout-Schritte und FAQ-Strukturdaten für interne Runbooks.
Kombinieren Sie die Richtlinie mit Disk- und Artefakt-Retention, Kapazitäts-Hüllkurven und Runner-Affinitätsregeln. Für zusätzliche dedizierte Hosts in Hongkong, Japan, Korea, Singapur oder den USA starten Sie bei den Preisen und halten Sie die Hilfe für SSH/VNC-Zugriffsmuster bereit.
Warum Checkout-Modus ein Scheduling-Problem ist, nicht nur Git-Kleinigkeit
Self-hosted macOS-Runner sind standardmäßig zustandsbehaftet: globale Caches, Keychain-Einträge auf Benutzerebene und Xcodes Standard-DerivedData überleben Jobs, sofern Sie sie nicht eingrenzen. Ein sauberer Klon pro Job isoliert Git-Objekte, aber nicht automatisch Compiler. Worktrees teilen eine Objektdatenbank — schnell — verstärken aber Fehler in Cleanup-Skripten. Behandeln Sie den Checkout-Modus als Teil Ihrer Blast-Radius-Story neben Secrets und Signaturidentitäten.
- Worktrees minimieren
git fetch-Bytes, wenn viele Branches denselben Revisionsstrom bauen. - Saubere Klone maximieren Isolation, wenn Post-Checkout-Hooks Tooling außerhalb des Baums mutieren.
- Hybride Muster (warmer Bare-Mirror + ephemere Worktrees) sind in großem Maßstab üblich, erfordern aber strikte Pfadkonventionen.
Entscheidungsmatrix A: Worktree, sauberer Klon oder Hybrid wählen
| Repo-Signal | Empfohlener Modus | Vorsicht |
|---|---|---|
| Monorepo, hoher Churn, geteilte Xcode-Version | Hybrid (Bare-Mirror + Worktrees) | DerivedData mit -derivedDataPath pro Worktree pinnen |
| Kleine App, wenige Abhängigkeiten, Reproduzierbarkeit nötig | Sauberer Klon pro Job | LFS-Bandbreite beobachten; Blobs auf dem Host mit Checksummenprüfung cachen |
| Release-Signierung mit hardwaregebundenen Identitäten | Dedizierter Host + sauberer Klon | Worktree-Basis niemals mit nicht vertrauenswürdigen Forks teilen |
| Fork-PR-Builds externer Beitragender | Ephemerer Klon auf eindeutigem Pfad | Geteilte Bare-Mirrors über Vertrauensgrenzen hinweg deaktivieren |
Entscheidungsmatrix B: Cache-Platzierung vs. Leckagerisiko
Der Checkout-Modus wählt, wo Git-Objekte leben; die Cache-Platzierung wählt, was den nächsten Job überlebt. Ohne beides zu alignen «klonen Sie sauber» und lecken trotzdem Compiler-Zustand über globale Pfade.
| Cache | Sichere Vorgabe auf M4-Runnern | Leckage-Symptom |
|---|---|---|
| Swift Package Manager | Pro Job SourcePackages unter Workspace-Temp |
Versionsdrift zwischen PRs bei globalem Cache ohne Lockfile-Hash |
| CocoaPods / Bundler | Vendor im Klon oder inhaltsadressierter Tarball-Cache | Native Extensions mit falschen Architektur-Flags |
| Xcode DerivedData | Immer pfadbezogen pro Job-ID | Flaky UI-Tests nach partiellem Index eines anderen Branches |
Ausführbare Disk-Budgets (Startpunkte)
- Bare-Mirror-Deckel: Monorepo-Mirrors unter 120 GB auf 512 GB-Hosts halten; mit auditierten Skripten stutzen, nicht manuell löschen.
- Parallele Worktrees: max. 4 pro Host, sofern IO-Metriken keinen anhaltenden Lese-Durchsatz-Spielraum zeigen.
- Sauberer Klon-Scratch: 2× größten erwarteten Arbeitsbaum für
git clone --depth 1plus LFS-Spitzen reservieren. - Alarm: Paging, wenn freier Speicher am CI-Volume länger als 5 Minuten unter 15 % fällt.
Audit-Hinweis: dokumentieren Sie, welcher Vertrauensstufe jede Runner-Gruppe angehört. Eine Worktree-Basis, die je einen Fork-PR ausgecheckt hat, darf später ohne dokumentierten Wipe keine signierten Release-Artefakte bauen.
Acht Rollout-Schritte
- Repos klassifizieren in vertrauenswürdig intern, Partner und öffentliche Forks.
- Messen p95 Checkout+Compile pro Stufe unter beiden Modi über einen Sprint.
- Pfadkonventionen implementieren wie
/ci/jobs/<id>/tree, die ausschließlich der Automatisierung gehören. - Post-Job-Hooks verdrahten, die Worktrees, DerivedData und Simulator-Caches an der Job-ID entfernen.
- Globale Caches blockieren, außer mit Content-Hash + Vertrauensstufe als Schlüssel.
- Metriken ergänzen für Checkout-Sekunden, LFS-Megabytes und freien Disk-Prozentsatz pro Host.
- Game-Day zweimal pro Quartal ein volles-Disk-Szenario.
- Hardware skalieren, wenn Budget riskantes Teilen erzwingt — NodeMac kann ohne Colo-Lead-Zeiten dedizierte Mac mini M4-Knoten pro Region hinzufügen.
FAQ
Wann ist git worktree auf geteilten Mac mini M4 CI-Hosts sicher?
Wenn jeder Worktree-Pfad pro Job isoliert ist, Hooks kontrolliert sind, Submodule gepinnt sind und Cleanup Worktree und colokalisierte Caches entfernt. Teilen Sie kein Bare-Repo mit interaktiven Entwicklersitzungen.
Warum scheitern saubere Klone weiterhin zufällig?
Meist globale Caches, LFS-Netzwerk oder Scanner, die Outputs berühren. Caches pro Job begrenzen und Fehler mit Netzwerkgraphen korrelieren.
Wie viel extra Disk für parallele Worktrees?
Pro gleichzeitigem Worktree einen Arbeitsbaum plus geteilten Objektspeicher budgetieren, plus pro Job DerivedData bei Xcode-Projekten.