Warum Ihr GitHub Actions macOS-Job in Queued hängen bleibt (nicht wegen langsamem Xcode)

VPSSpark CI-Queue-Diagnose-Standard (Cloud-Mac-CI #2). Lesereihenfolge: Hook → Formel → Symptome → Failure Model → Hard Rules → Runbook → FAQ. Verwandt: #1 Kapazität · #5 Skalierungs-Incident · #3 Self-Hosted-TCO · #8 Build-Speed.

1 · Hook: der überraschende Befund

In Slack heißt es schnell „CI ist langsam“. In GitHub Actions sind Queued und In progress aber verschiedene Metriken. Ohne die Frage „dominiert Wartezeit die Laufzeit?“ landet man bei Xcode-Upgrades oder mehr Abrechnungsminuten—beides löst keine Runner-Warteschlange. Dieser Artikel ist die Norm für genau diese Trennung.

2 · Kern: eine Formel

Alles Folgende entfaltet diese eine Prüfung. In euer On-Call-Wiki kopieren.

CI queue problem  ⇔  wait time  >>  run time

Viele DACH-Teams mischen macos-latest mit Self-Hosted und wundern sich über „Minuten übrig, trotzdem Queued“. Dahinter steckt fast immer die Verwechslung von minutes (Abrechnung) und concurrency (gleichzeitige Slots). Nur bei true an Pool- und Trigger-Design drehen.

3 · Symptom: Queued ≠ Running

Bei GitHub Actions heißt Queued: Job ist im Workflow, aber noch kein Runner-Slot. Unter In progress laufen Checkout, xcodebuild und Signing. Ein roter PR über eine Stunde wird als „langsamer Build“ gemeldet—in der Timeline steht oft 52 Minuten Warten, 11 Minuten Laufen.

Typische Fehlfixes: Xcode bumpen, timeout-minutes erhöhen, mehr GitHub-Minuten kaufen. Queued-Zeit zählt oft nicht in das Timeout, das ihr meint. Timeout allein entleert die Queue nicht.

Messen mit Job-Ausführungszeit (queue_wait_seconds vs. Laufzeit). Wöchentliches P95 zeigt Trigger Explosion vor dem Freitags-Merge-Rush.

Wenn im Team „DerivedData“ fällt, obwohl die Badge lange Queued zeigt, liegt die Beobachtung in der falschen Phase. Im Runbook Warte- und Laufzeit getrennt loggen—sonst wiederholt sich derselbe Fehlkauf.

4 · Erklärung: CI Queue Failure 3 Layer Model

Bei wait time >> run time liegt eine (oder mehrere) dieser SRE-Schichten vor.

Capacity Limit — trifft gehostete macOS-Runner und das Org-macOS-Concurrency-Cap (Limits). Pool Misdesign — häufige Wurzel: L2 auf PR, gemischte Pools. Trigger Explosion — YAML fixen, nicht Hardware. (Failure-Layer ≠ Job-Tiers L0/L1/L2.)

Die drei Layer schließen sich nicht aus: Freitagabend mehr Matrix (Trigger), Archive blockiert fast (Pool), Hosted-Kontingent leer (Capacity)—das „Triple“ sieht man im 20-Personen-Fall #5 regelmäßig. An der Signale-Spalte anfangen.

5 · Fix: CI Hard Rules (MUST NOT verletzen)

Normative Sprache fürs Runbook—keine Empfehlungen. Verstöße = Incident.

Rule 1: PR MUST NOT run L2
                Rule 2: L2 MUST run on isolated pool  (macos-archive)
                Rule 3: fast pool MUST remain unblocked  (fast ≠ archive)

                # Mapping
                PR     → L0 + L1 only     → macos-fast
                main   → L2 only            → macos-archive

Job-Tier-Referenz (nur Umsetzung der Hard Rules):

„Nur einmal Archive auf dem PR“ wirkt harmlos—38 Minuten L2 auf einem Label halten alle L0/L1 in Queued. Ausnahmen zerstören Pool-Design; Release-Jobs auf main / Schedule legen.

jobs:
                  pr-fast:
                    if: github.event_name == 'pull_request'
                    runs-on: [self-hosted, macos-fast]

                  release-archive:
                    if: github.ref == 'refs/heads/main' || github.event_name == 'schedule'
                    runs-on: [self-hosted, macos-archive]

Runner-Topologie: Elastic vs. Always-on · #1 Sizing · nach gesunder Queue → #3.

6 · Runbook: eine Seite (On-Call)

0. CI queue problem ⇔ wait time >> run time  ?  ─No→ #8
                1. Layer: Capacity | Pool Misdesign | Trigger Explosion
                2. MUST: Rule1 PR no L2 · Rule2 L2 isolated · Rule3 fast unblocked
                3. PR workflow has no archive/export/upload ?
                4. wait P95 < 8min → then size runners (#3)

Einzeiler: Die meisten macOS-CI-queued-Fälle sind L2 auf dem PR-Pfad—not fehlende Hardware. macOS runner queued = Pool-Sättigung; wait >> run, dann Failure Model, dann Hard Rules.

Postmortems mit „wir haben Runner gekauft“ ohne Rule 1–3 im Repo wiederholen das Muster. PR-Template-Checkbox „kein Archive-Job auf PR“ senkt die Rückfallrate spürbar.

7 · FAQ