2026 Kurzzyklus-Burst-Builds: GitLab CI mit selbst gehosteten macOS-Runnern auf Cloud-Mac — Shell-Executor, Cache-Schlüssel und Tag-Strategie; Entscheidungsmatrix und ausführbare Parameter-FAQ bei Mix mit GitHub Actions

Wenn Release-Fenster und Hotfix-Tage zusammenfallen, entscheidet weniger die „theoretische Build-Zeit“ als die Frage, ob ein macOS-fähiger Runner sofort verfügbar ist. GitLab CI mit selbst gehosteten Runnern auf einem dedizierten Cloud-Mac schließt diese Lücke: Shell-Executor statt schwerer Virtualisierung, vorhersagbare Tags und ein Cache-Schlüssel, der Xcode- und Lockfile-Realität abbildet. Viele Teams betreiben parallel GitHub Actions — dann braucht es eine klare Matrix, welche Plattform Apple-Credentials berührt und wo nur Artefakte fließen. Zum Vergleich elastischer Pools versus dauerhafte Knoten bei GitHub Actions siehe 2026 Kurzzyklus-Spitzen in CI: selbst gehostete GitHub Actions macOS Runner — elastischer Cloud-Mac-Pool oder dauerhafte Knoten?.

Shell-Executor auf Cloud-Mac: was der Runner wirklich tut

Der Shell-Executor startet Jobs im Login-Kontext eines CI-Benutzers — ideal für Xcode, Fastlane und Codesigning, weil Schlüsselbund und Toolchain sich wie auf einem Entwicklerrechner verhalten. Auf einem Cloud-Mac sollten Sie einen dedizierten Unix-User pro Runner-Instanz oder klar getrennte Home-Verzeichnisse nutzen, damit Umgebungsvariablen und CocoaPods-Caches nicht zwischen Projekten vermischen. Der Runner-Prozess bleibt nach einem Job nicht „warm“ im Sinne eines Containers; was zählt, ist ein konsistentes PATH, fest angebundene Xcode-xcode-select-Version und dokumentierte Voraussetzungen in der .gitlab-ci.yml. Für Burst-Last empfiehlt sich, concurrent bewusst niedrig zu halten und lieber einen zweiten Runner mit eigenen Tags zu registrieren, statt einen einzelnen Knoten zu überzeichnen.

Cache-Schlüssel: welche Felder Apple-Builds stabil halten

GitLab-Caches leben pro Schlüssel — ein zu grober Schlüssel teilt Artefakte zwischen Branches und riskiert inkrementelle Fehlentscheidungen; ein zu feiner Schlüssel verhindert Treffer und macht Burst-Builds wieder langsam. Praxisnahe Kombination: Projekt-Slug, Hash der Lockfiles (Gemfile.lock, Podfile.lock, Package.resolved), Xcode-Build-Nummer aus xcodebuild -version und explizit arm64 bzw. x86_64, falls noch Rosetta-Pfade existieren. Pipelines, die nur Dokumentation bauen, sollten andere Cache-Keys nutzen als Archiv-Jobs — sonst verdrängen sich die Einträge gegenseitig. Ergänzend lohnt ein Blick auf Remote-DerivedData-Strategien in Kurzzyklus-Cloud-Mac-CI 2026: Remote-Build-Cache (DerivedData, Pods, sccache) vs. lokale Knoten-SSD, wenn der Shell-Executor weiterhin lokal schreibt, aber der Speicher zentral gebündelt werden soll.

cache:
  key:
    files:
      - ios/Podfile.lock
      - ios/Gemfile.lock
  paths:
    - ios/Pods/
    - .bundle/
# DerivedData optional über artifacts oder externes Volume spiegeln

Tag-Strategie: GitLab-tags und GitHub Actions nicht verwechseln

GitLab wählt Runner über YAML-tags:; GitHub nutzt runs-on-Labels — gleiche Wörter in beiden Systemen führen in Playbooks zu fatalen Annahmen. Empfehlung: Präfixe wie gl-macos-arm versus gha-macos-14 in interner Doku und im Terraform-/Ansible-Namen. Burst-Jobs, die nur schnell linten, erhalten schmalere Tags als Release-Pipelines mit Verteilungszertifikaten. So bleibt der Blast-Radius begrenzt, wenn ein Runner-Knoten kompromittiert oder veraltet ist.

FAQ: ausführbare Runner-Parameter (Kurzreferenz)

concurrent begrenzt parallele Jobs pro Maschine — für Xcode typisch 1–2 auf Consumer-Hardware, auf Cloud-Mac M4 oft 2–3, wenn RAM und Disk-IO gemessen sind. check_interval steuert, wie oft der Runner die GitLab-Instanz abfragt; zu aggressive Werte erhöhen Last und Rate-Limits, zu hohe Werte verlängern die wahrgenommene Warteschlange. output_limit kürzt extrem lange xcodebuild-Logs in der UI — bei Debug-Sprints temporär anheben, danach wieder senken. shutdown_timeout lässt laufende Jobs nach Runner-Stop noch Artefakte und Signaturen sauber beenden, statt harte Abbrüche mitten im Archiv-Schritt. Dokumentieren Sie diese Werte im Repo neben der .gitlab-ci.yml, damit On-Call dieselben Zahlen sieht wie Entwicklung.