2026 Exklusiver Fern-Mac iOS/macOS-CI: xcodebuild -showBuildTimingSummary & XCLogParser auf SSH-headless — Build-Zeit-Regression messen: Vergleichstabelle, Schwellenwert-Skript & Pipeline-Schritte + FAQ
Wenn Ihre Pipeline auf einem dedizierten Fern-Mac per SSH läuft, reicht „grün“ nicht: Sie brauchen eine stabile Zeitreihe für Compile, Link und teure Swift-Makros. Dieser Artikel zeigt, wie -showBuildTimingSummary und XCLogParser zusammen eine reproduzierbare Regressionsschleife bilden — inklusive Tabelle, Bash-Schwellenwert und konkreter Job-Reihenfolge. Für eingehende Webhooks und Rate-Limits auf demselben Knoten siehe
OpenClaw Webhooks für GitHub/GitLab CI auf exklusivem Fern-Mac (SSH);
für isolierte Scan- und Compliance-Workloads ergänzt
iOS-Sicherheit & Datenschutz-Compliance auf dediziertem Mac mini M5
das Bild eines getrennten Runner-Profils.
1. Problemstellung: Warum Build-Zeit auf headless-SSH anders „flattert“
Ohne GUI teilen sich Simulator-Instanzen, Derived-Data-Caches und parallele PRs dieselbe Maschine. Typische Regressionen sind plötzlich längere Swift-Compile-Phasen, mehr Linker-Arbeit durch geänderte LTO-Flags oder ein neuer Makro-Pfad — nicht unbedingt ein fehlgeschlagener Test. Ziel ist ein einheitlicher Messpunkt am Ende jedes Laufs, der mit demselben Benutzer und derselben Xcode-Version vergleichbar bleibt.
2. Vergleich: -showBuildTimingSummary vs. XCLogParser vs. rohes Log
Die folgende Matrix fasst zusammen, wann welche Quelle ausreicht — und wann Sie beides kombinieren sollten.
| Signalquelle | Stärken | Grenzen | Typischer SSH-CI-Einsatz |
|---|---|---|---|
xcodebuild … -showBuildTimingSummary |
Schnell, kein Zusatzartefakt; aggregierte Phasen direkt in stdout/stderr | Weniger granular als vollständiger Activity-Log; schwer maschinenlesbar ohne Parser | Täglicher „Smoke“-Job: Trend über Median/Perzentil |
XCLogParser auf .xcactivitylog |
Strukturierte Targets/Tasks, JSON/HTML-Reporter, Diff-freundlich | Benötigt Pfad zum Log; Tool muss auf dem Runner installiert sein | Wöchentlicher Deep-Dive; Top-N langsame Swift-Dateien |
Rohes xcodebuild-Log (grep) |
Null Setup | Brüchig bei Xcode-Textänderungen; keine stabilen Spalten | Nur Notfall-Heuristik, kein KPI-Board |
Hinweis: Kombinieren Sie die Summary mit einem archivierten Log (tee), damit XCLogParser dieselbe Datei offline nachparsen kann.
3. Pipeline auf SSH-headless: empfohlene Reihenfolge
- Umgebung pinnen:
DEVELOPER_DIR, ein fester Derived-Data-Pfad pro Job-ID, eindeutiger Simulator-Name. - Checkout & Caches: Git shallow + optional SPM/Derived-Cache — aber Key aus Lockfile + Xcode-Build, nicht nur Branchname.
- Build mit Timing:
xcodebuild … build -showBuildTimingSummary 2>&1 | tee build.log. - Log-Pfad ermitteln: Activity-Logs liegen unter Derived Data; viele Teams kopieren sie mit
findin ein Artefaktverzeichnis. - XCLogParser: JSON-Report erzeugen und als Pipeline-Artefakt hochladen.
- Schwellenwert: Bash-Skript (Abschnitt 4) vergleicht Kennzahlen gegen Baseline aus
main.
Auf exklusivem Fern-Mac sollte der SSH-Login derselbe Benutzer sein wie der CI-Agent — sonst unterscheiden sich Keychain, Simulator-Berechtigungen und Cache-Pfade von Ihrer manuellen Diagnose-Session.
4. Schwellenwert-Skript (Bash, vereinfacht)
Das folgende Beispiel erwartet, dass Sie aus der Summary oder einem separaten Schritt eine Zahl TOTAL_SEC exportieren (hier Platzhalter). Passen Sie Parser und Metriknamen an Ihren Reporter an.
#!/usr/bin/env bash
set -euo pipefail
# Beispiel: Gesamt-Sekunden aus einer JSON-Zeile von XCLogParser
CURRENT="${CURRENT_BUILD_SEC:?set from CI step}"
BASELINE="${BASELINE_BUILD_SEC:?store per scheme in artifact registry}"
RATIO_MAX="1.15" # +15 % Regression
awk -v c="$CURRENT" -v b="$BASELINE" -v r="$RATIO_MAX" 'BEGIN {
if (b <= 0) { print "baseline missing"; exit 2 }
if (c/b > r) { printf "REGRESSION: %.3fx (cap %.2f)\n", c/b, r; exit 1 }
print "OK"
}'In der Praxis speichern Sie BASELINE_BUILD_SEC als commit- oder taggebundenes Artefakt (z. B. letzter grüner Lauf auf main) und aktualisieren es nur nach expliziter Review — sonst „lernt“ die Pipeline lautlos, langsamer zu werden.
5. Operative Leitplanken
- Parallelität: Begrenzen Sie
-jobsund gleichzeitige Simulatoren pro Host, damit Trends vergleichbar bleiben. - Disk I/O: NVMe fast voll = schleichende Link-Phasen; monitoren Sie freien Speicher unabhängig vom Build-Ergebnis.
- Netzwerk: SPM-Resolve-Zeit nicht mit Compile verwechseln — in der Summary getrennt betrachten.
6. FAQ
F1: Reicht -showBuildTimingSummary allein für PR-Gates?
Für grobe „rote Linie“-Checks ja; für Root-Cause (welche Swift-Datei, welches Target) brauchen Sie strukturierte Logs — typischerweise XCLogParser.
F2: Muss XCLogParser auf dem Runner global installiert sein?
Nein — Brew, Mint oder ein eingechecktes Binary im Repo sind üblich. Wichtig ist eine fixierte Version in der Pipeline, damit Reporter-JSON stabil bleibt.
F3: Warum schwankt die Zeit trotz identischem Commit?
Kalter vs. warmer Derived-Data-Cache, Hintergrund-mdworker, oder ein zweiter Job auf derselben Kiste. Messen Sie mehrere Läufe und nutzen Sie Median statt Einzelwert.
F4: Passt das zu GitHub Actions / GitLab CI auf selbst gehostetem Mac?
Ja — die Schritte sind runner-agnostisch, solange Umgebungsvariablen und Pfade unter SSH reproduzierbar gesetzt sind.
Warum Mac mini & macOS dieses Timing-Setup tragen
Zuverlässige Build-Zeit-Trends brauchen vorhersagbare Toolchains, konsistente Benutzerkonten und geringe Hintergrundüberraschungen — genau dort glänzt macOS auf einem dedizierten Knoten. Ein Apple-Silicon Mac mini bleibt unter dauerhaftem xcodebuild-Last energieeffizient (sehr niedriger Leerlauf-Stromverbrauch), während Gatekeeper, SIP und FileVault zusätzlich zu einem schlanken CI-Account passen und Security-Reviews erleichtern.
Wenn Sie XCLogParser-Reports und Timing-Summaries monatelang vergleichbar halten wollen, lohnt sich Hardware, die dieselbe Rolle stabil spielt — der Mac mini M4 bleibt 2026 ein starker Einstieg mit niedrigem Gesamtbesitzkosten für exklusive Fern-Mac-CI; die Startseite führt zu aktuellen Paketen.