Große Apple-Silicon-Workstations sind teuer genug, dass Plattformteams unbequem fragen: dürfen GitLab Runner und ein selbst gehosteter GitHub-Actions-Runner dieselbe Bare-Metal-Mac teilen, ohne dass Releases zur Lotterie werden? Ja — wenn Sie den Host als Scheduling-Problem mit Sicherheitsgrenze behandeln, nicht als zwei Installer, die zufällig auf dieselbe SSD passen. Dieses FAQ vergleicht greifbare Regler: Parallelitäts-Kontingente, Tag-Routing, Secret-Isolation und NVMe-Cache-Layout, damit Sie das Architekturmemo gegenüber Security und Mobile-Lead verteidigen können. Wenn mehrere Runner Cache und Arbeitsverzeichnisse teilen, lohnt parallel unsere FAQ zu mehreren selbst gehosteten Mac-Runnern, GitHub Actions Cache und persistenten Festplatten.
1. Wann Co-Hosting sinnvoll ist — und wann nicht
Co-Hosting lohnt sich, wenn beide Ökosysteme dauerhaft bleiben, Sie ohnehin für einen speicherreichen Mac Studio oder eine Rack-Mac-mini-Farm zahlen und die Last stoßartig, aber nicht feindlich ist. Lassen Sie es, wenn die Compliance harte Isolation zwischen SCMs verlangt, wenn eine Seite exklusiv GPU oder Simulator-Sättigung braucht oder wenn Sie keine gemeinsame DEVELOPER_DIR-Politik durchsetzen können. Für stabile Installationspfade, Docker und Dauerbetrieb auf Remote-Macs — dieselbe operative Disziplin wie bei Runner-Co-Hosting — siehe
OpenClaw Remote-Mac-Bereitstellung in der Praxis.
2. Parallelitäts-Kontingente: CPU, RAM und Job-Slots explizit budgetieren
GitLab Runner bietet global concurrent plus Executor-Limits; der GitHub-Runner-Dienst respektiert --max-jobs (oder plist-Einstellungen) und serverseitige Concurrency-Groups in Workflows. Keines der Produkte kennt die Warteschlagentiefe des anderen — Sie müssen gleichzeitige Compile-lastige Jobs begrenzen, damit zwei xcodebuild archive-Läufe nicht um dieselbe Speicherbandbreite ringen. Starten Sie mit einem einfachen Budget: einen „schweren“ Slot für Release-Züge reservieren und N leichte Linter zulassen, dann P95-Schwanzlatenz statt Durchschnitts-CPU messen. Dokumentieren Sie die Matrix im Runbook, damit On-Call-Engineer:innen Limits nicht „vorübergehend“ während eines Brandes anheben.
3. Tag-Routing: Auswahlregeln auf beiden Plattformen ehrlich halten
Unbeabsichtigtes Cross-Scheduling ist der schnellste Weg, Secrets über Organisationsgrenzen zu leaken. Nutzen Sie sich gegenseitig ausschließende Tags wie gitlab-only versus gha-only bei der Runner-Registrierung und spiegeln Sie dieselben Zwänge in Workflow-runs-on-Labels und GitLab-tags-Blöcken. Generische Labels wie macos oder apple-silicon auf geteilten Hosts vermeiden Sie, außer jeder Job ist gleich vertrauenswürdig. Kombinieren Sie Tags mit Runner-Gruppen- oder Repo-Allowlists, damit ein geforkter Workflow keinen ähnlich benannten Runner registriert und Jobs abschöpft.
4. Secret-Isolation: zwei Anbieter, eine Keychain-Oberfläche
Beide Runner führen Shell-Schritte als lokalen Benutzer aus — damit sind Umgebungsvariablen, Dateien unter ~/Library und die Login-Keychain gemeinsame Angriffsfläche, sofern Sie nicht partitionieren. Praktische Muster: getrennte OS-Benutzer mit eigenen Keychain-Dateien, CI-spezifische Signing-Identitäten mit engen Provisioning-Profilen, kurzlebige OIDC-Token statt langlebiger PATs wo unterstützt und niemals dieselbe RUNNER_TEMP-Wurzel. Rotieren Sie Credentials pro Plattform mit unterschiedlichem Rhythmus, damit ein kompromittiertes GitLab-Token nicht automatisch Schreibzugriff auf GitHub-Repos bedeutet.
5. NVMe-Cache-Partitionierung: drei Layouts vergleichen, bevor Sie formatieren
Caches kollidieren schneller als CPUs. Entscheiden Sie, ob GitLab-Job-Workspaces, GitHub ACTIONS_RUNNER_DIR, DerivedData und SwiftPM-Caches auf einem APFS-Volume mit strikten Unterordnern pro Job oder auf getrennten APFS-Volumes mit Quotas leben. Remote-Build-Caches helfen weiter, aber lokale NVMe-Latenz gewinnt bei inkrementellen Übersetzungen.
| Layout | Vorteile | Risiken |
|---|---|---|
| Ein Volume, namespaces Pfade | Einfache Backups; freien Speicher zentral überwachen | Fehlkonfigurierte Bereinigung kann beide Stacks treffen |
| Zwei APFS-Volumes auf derselben NVMe | Klare Ownership pro Runner; optionale getrennte Verschlüsselungsschlüssel | Weiterhin gemeinsame IOPS; Quotas nach Xcode-Upgrades nachjustieren |
| Zweite schnelle SSD per Thunderbolt | Härtere Entkopplung; Platz für heiße Cache-Tier | Kabel- und Strombudget; Snapshot-Richtlinie pro Datenträger |
Unabhängig vom Layout sollten Bereinigungsjobs niemals das Toolchain-Volume mit DerivedData eines anderen Stacks verwechseln; versionieren Sie Skripte und testen Sie sie auf einem Staging-Host, bevor sie in launchd landen. Wenn Sie Remote-Caches (Bazel, Gradle, Xcode-Compilation-Cache) einsetzen, dokumentieren Sie getrennte Buckets oder Präfixe pro SCM, damit ein aggressiver GC-Lauf nicht die Artefakte der anderen Plattform löscht.
6. Start-Checkliste
Gehen Sie die Liste mit DevOps und App-Security durch, bevor Sie den Infra-Change mergen.
- Schriftliches Parallelitäts-Budget pro Host mit Links zu Monitoring-Dashboards
- Runner-Tags gegen jeden Workflow und jeden
.gitlab-ci.yml-Eintrag verifiziert - Getrennte Secret-Stores oder Keychains pro Plattform, mit benannten Rotation-Ownern
- Platten-Warnschwellen je NVMe-Volume oder Cache-Wurzel, nicht nur Systemvolume
- Game-Day: beide Warteschlangen gleichzeitig spiken und prüfen, dass kein Job den falschen Cache-Namespace stiehlt
Warum Bare-Metal-Apple-Silicon für gemischte Runner weiterhin siegt
Virtualisierte macOS-CI wird besser, aber zwei native Runner-Stacks auf echtem Apple Silicon vermeiden eine ganze Klasse aus Nested-Virtualisierung und USB-Simulator-Bugs. Mac mini- und Studio-Klasse liefern hohe Speicherbandbreite bei sehr niedriger Leerlaufleistung — relevant, wenn Sie warme Worker für GitLab und GitHub online halten. macOS bündelt Xcode, Codesigning und Gatekeeper-Erwartungen ohne Linux-Shim; FileVault plus System Integrity Protection geben Security-Reviewer:innen eine vertraute Geschichte für unbeaufsichtigte Build-Maschinen. Brauchen Sie zusätzliche dedizierte Cloud-Macs, um eine Anbieter-Warteschlange abzuziehen, ohne On-Prem-Kapazität anzufassen, bleibt Mac mini M4 ein pragmatischer Burst-Tier: sauber provisionieren, Image pinnen, dieselbe Runner-Disziplin wie zu Hause anwenden.
Wenn Sie den Pool mit On-Demand-Dedikatrechnern erweitern möchten, fasst die Macstripe-Startseite Regionen und Modelle zusammen — gleichen Sie sie mit der dokumentierten Tag- und Cache-Politik ab. Wenn Sie jetzt Kapazität ergänzen wollen, ist ein guter Zeitpunkt: Jetzt erhalten Sie über dieselbe Startseite einen Überblick und können Messreihen fixieren.
