CI ist tot – GitHub merkt es noch nicht

Wenn du GitHub Actions oder selbst gehostete macOS Runner betreibst, lauten die häufigsten Beschwerden 2026 sehr konkret: längere Queues, schwankende Xcode-Build-Zeiten, wiederholte Retries pro PR, CI mal grün mal rot. Dieser Artikel ordnet das in vier Schichten ein – zuerst die technischen Symptome, dann wie Agents CI „loopifizieren“, und schließlich die Rolle von Cloud Mac. Die Überschrift „CI ist tot“ klären wir im FAQ am Ende; der Fließtext startet bei Fehlerbildern, die du direkt wiedererkennst.

1 · Erste Schicht: Warum GitHub Actions 2026 „langsamer, unberechenbarer, flaky“ wirkt

In den letzten sechs Monaten hören wir von iOS-, Flutter- und macOS-Teams dasselbe Muster – nicht „CI ist ein veraltetes Konzept“, sondern dass die folgenden vier Problemklassen gleichzeitig zunehmen.

1.1 macOS-Runner-Queue

Auf gehosteten macos-latest-Runnern ist die Queued-Zeit oft länger als die eigentliche Build-Zeit. In der Job-Timeline: 40 Minuten warten, 12 Minuten laufen – das Team optimiert noch xcodebuild-Flags. Die Diagnoseformel bleibt wait time >> run time, ausführlich im macOS-Runner-Queue-Runbook. 2026 verlängern sich Queues, weil das macOS-Concurrency-Limit nicht mit der Job-Anzahl im Repo mithält – und weil Archive- und Schwergewichts-Jobs Slots blockieren und schnelles PR-Feedback mit in die Warteschlange ziehen.

1.2 Schwankende Xcode-Build-Zeiten

Derselbe Commit, erneut ausgeführt: in CI mal 18, mal 31 Minuten Xcode-Compile, lokal stabil bei ~15 Minuten. Typische Faktoren: Cold Start des Runners, DerivedData-Cache-Miss, CocoaPods-Neuauflösung, Xcode-Patch-Level im Image weicht vom lokalen Mac ab. Allein betrachtet wirkt das wie „Cache falsch konfiguriert“ – wenn aber jeder Retry in einer kalten Umgebung landet, wird die Varianz zu „CI ist nicht vertrauenswürdig“.

1.3 Retries außer Kontrolle

Neben explizitem retry-on-failure in Workflows gibt es zunehmend implizite Retries: Agent oder Bot liest Logs → patcht → push → triggert Actions erneut. Ein PR geht von „zwei menschliche Pushes“ zu „acht maschinelle Pushes“; Minutes-Rechnung und Queue-Druck steigen parallel. Du vermutest flaky Tests – tatsächlich läuft derselbe PR in CI mit unterschiedlichem Code über mehrere Runden.

1.4 Flaky CI: mal grün, mal rot, schwer reproduzierbar

Klassisch: sporadische Test-Timeouts, Simulator-Startfehler, Keychain-Sperren beim Signieren. 2026 kommt eine Schicht dazu: jede Agent-Runde liefert einen anderen Diff – die Frage „flaky Test oder kaputter Fix?“ ist kaum beantwortbar. Der Satz, der Release-Engineers am meisten schmerzt: „Gestern Abend war CI grün, heute Morgen derselbe Tag wieder rot.“

2 · Zweite Schicht: Nicht „CI wurde schlechter“, sondern CI wurde loopifiziert

Queue, Cache und Tests einzeln zu fixen, hilft oft nur eine Runde. Zusammen betrachtet zeigt sich eine gemeinsame Linie: CI ist keine einmalige Verifikation mehr, sondern eine Schleife „Fehler → Fix → erneut laufen“. Vor Agents lief diese Schleife im Kopf der Engineers; heute steckt sie in der Infrastruktur – Modell liest Logs, erzeugt Patches, triggert Workflows automatisch.

Die typische Kette ist längst Standard:

• PR öffnen → CI rot (Test / Build)
• Agent liest Actions-Logs → Fix-Commit
• Push → neuer Workflow → evtl. wieder rot → erneuter Fix
• Bis grün – oder bis ein Mensch stoppt / Tokens leer sind

Formal heißt es noch GitHub Actions / CI; faktisch ist es ein Agent-Retry-Loop. Du kämpfst nicht mehr mit „einem fehlgeschlagenen Build“, sondern mit der Wahrscheinlichkeitsverteilung vieler Versuche – daher die Symptome aus Schicht 1: Queue voll durch Mehrfach-Jobs, Xcode-Zeit driftet durch Cold Starts, Flakiness weil Code und Umgebung pro Runde variieren.

Hier hilft ein etwas abstrakter, aber handhabbarer Begriff: Klassisches CI setzt Determinismus voraus – gleicher Commit, gleiche Umgebung, reproduzierbares Ergebnis. Nach der Agent-Schleife wird der Pfad probabilistisch – welcher Versuch wird grün, wie viele Commits dazwischen, ob Archive versehentlich läuft. Das erklärt, warum „nur mehr Cache“ nicht alles löst.

GitHub optimiert weiter Workflows, Runner und Cache – für einzelne deterministische Jobs. Wenn im Repo standardmäßig Agent-Loops laufen, helfen diese Verbesserungen, stoppen aber nicht den Multiplikatoreffekt „Job-Anzahl × Retry-Runden“. Darum meint die Überschrift „GitHub merkt es noch nicht“: Die Produktstory bleibt CI/CD, die Nutzung driftet zum automatischen Fix-Loop.

3 · Dritte Schicht: Strukturwandel – von CI-Pipeline zu Retry-Loop + Ausführungsbasis

Symptome (Schicht 1) und Ursache (Schicht 2) zusammengezogen: CI wird von einer linearen Pipeline zu einem Ausführungssystem mit Rückkopplung.

Altes Modell: Code → Build → Test → Result – ein Fehler stoppt die Linie. Neues Modell: Code → Agent → Modify → Execute → Retry → … → Result – Fehler ist Teil der Schleife, kein Endpunkt. Das grüne Häkchen in GitHub beruhigt noch, aber die Semantik ändert sich – vielleicht erst beim vierten Versuch grün, mit geändertem Commit dazwischen.

Ein neuer, aber ingenieursnaher Begriff: execution substrate (Ausführungsbasis) – der Agent darf Code ändern, aber Kompilieren, Signieren und Upload müssen auf einer stabilen, reproduzierbaren macOS-Ausführungsfläche landen. Serverless-Jobs sind zu kurz, State geht verloren; lokale Macs schlafen und upgraden Xcode; gehostete Runner queuen und driften in der Spezifikation. Cloud Mac füllt genau diese Lücke: dauerhaft online, Toolchain pinnbar, Umgebung snapshot-fähig – kein „Remote Desktop“, sondern die Schicht im Retry-Loop, die möglichst deterministisch bleiben sollte.

Die Ausführungsverantwortung verschiebt sich: Früher schrieb der Mensch Workflows, die Maschine führte aus; heute definiert der Mensch Grenzen (was in PRs, was in Archive, maximale Retry-Runden), der Agent probiert Pfade innerhalb der Grenzen, der Mensch akzeptiert das Endergebnis. macOS/iOS-Teams spüren das am stärksten – Signierung und Archive sollten nicht unbegrenzt in der Retry-Schleife wiederholt werden, sonst bedeutet Grün nicht „release-fähig“.

4 · Vierte Schicht: Ausführungsfläche mit Cloud Mac stabilisieren (sofort umsetzbar)

Du musst weder auf GitHubs Narrative warten noch Actions abschaffen. Gegen loopifiziertes CI haben sich bei VPSSpark-Kunden diese vier Maßnahmen am zuverlässigsten bewährt – und das ist die Differenzierung von Cloud Mac gegenüber gehosteten Runnern.

4.1 Pool-Trennung: Schadensradius von Retries begrenzen

PRs laufen nur L0/L1 (analyze, Unit-Tests, Simulator-Build), kein Archive in PRs; Release, IPA und Notarisierung nur in isolierten Pools auf main/tags. Wie wild der Agent-Loop auch rotiert – ein 35-Minuten-Archive blockiert nicht den Fast-Pool und queuet nicht das ganze Team. Harte Regeln im CI Hard Rules-Artikel; Flutter-Dual-Pool-Topologie in 2 Cloud Macs: fast/archive.

4.2 Warm environment: Kein Cold Start pro Retry

PUB_CACHE, DerivedData und Pods-Download-Cache persistent halten; Runner autostart, 7×24 online. Beim zweiten Agent-Retry sollte kein 15-Minuten-pod install mehr laufen – sonst wird Xcode-Varianz fälschlich als „Projekt wird langsamer“ gelesen. Cloud Mac kauft Kosten für Umgebungserhalt, nicht nur CPU-Minuten pro Job.

4.3 macOS execution substrate: Toolchain-Version fixieren

Flutter/Xcode-Hauptversion per Image oder fvm pinnen; Archive-Maschine und Fast-Pool physisch getrennt, kein geteiltes DerivedData. Jede Retry-Runde sollte auf dasselbe Distribution-Zertifikat, dieselben CLTs laufen – Voraussetzung für auditierbares iOS-CI. Grenzen selbst gehosteter Runner: GitHub-Dokumentation.

4.4 Retry isolation: Obergrenzen für den Loop

Workflow-Ebene: concurrency bricht alte Runs desselben PRs ab; für Agent-Trigger eigene Timeouts und maximale Push-Anzahl; Signier-Maschine nur für Release-Pool. Syntax: Workflow-Dokumentation. Ziel ist nicht, Agents zu verbieten, sondern den Loop in kontrollierbaren Grenzen zu halten.

5 · FAQ