Wie exportieren Sie xcresult aus Remote-Mac-CI? Leitfaden 2026

Ab dem nächsten Testlauf sollten Sie xcodebuild test einen eigenen Pfad für das Ergebnis-Paket geben und das erzeugte xcresult als Workflow-Artefakt hochladen; auch bei einem fehlgeschlagenen Test muss der Upload-Schritt noch laufen. Diese Woche sollten Sie einen erfolgreichen und einen fehlgeschlagenen Lauf herunterladen und das Paket tatsächlich in Xcode oder mit xcresulttool öffnen, statt nur den Status der CI-Ausführung zu prüfen.

Dieser Leitfaden richtet sich an CI-Verantwortliche, die Testergebnisse von einem Remote-Mac zuverlässig zurückholen müssen.
Testingenieure erhalten einen Ablauf zum Prüfen von Fehlerdetails, Protokollen und gegebenenfalls Abdeckungsdaten.
Veröffentlichungs- und Plattformverantwortliche können damit Namen, Aufbewahrung und Zugriffsgrenzen festlegen.

CI-Verantwortliche: Erst klären, ob der Testlauf ein Ergebnis-Paket erzeugt

Ein Xcode-Testlauf kann ein Ergebnis-Paket mit Testinformationen erzeugen; ein erfolgreiches Kompilieren allein belegt jedoch nicht, dass überhaupt Tests ausgeführt wurden. Prüfen Sie daher zuerst den tatsächlichen xcodebuild-Aufruf und den Workflow-Schritt, der ihn startet. Apple beschreibt, wie Tests ausgeführt und Ergebnisse in Xcode interpretiert werden; die Dokumentation grenzt die Testergebnisse von einer bloßen Statusmeldung des CI-Systems ab (Apple-Dokumentation zur Ausführung und Auswertung von Tests).

Das ist die erste häufige Fehlerquelle: Ein Job baut das Projekt oder erstellt ein Archiv, aber sein Workflow enthält keinen Testaufruf. In diesem Fall gibt es kein Testergebnis-Paket, das ein späterer Upload-Schritt sichern könnte. Ein Build-Protokoll oder ein erzeugtes Archiv ersetzt dieses Paket nicht. Behandeln Sie deshalb xcresult, gewöhnliche Build-Ausgaben und Release- beziehungsweise Archivdateien in Ihrer Pipeline als unterschiedliche Datenarten.

Prüfen Sie den Befehl im Workflow, nicht nur den Jobnamen. Ein Job mit der Bezeichnung „Test“ kann durch Bedingungen, Eingaben oder eine geänderte Scheme-Auswahl trotzdem nur einen Build ausführen. Apple führt xcodebuild als Kommandozeilenwerkzeug für Xcode auf; die verfügbaren Optionen hängen von der installierten Werkzeugversion ab. Verwenden Sie für die konkrete Syntax die Apple-Referenz zu den Xcode-Kommandozeilenwerkzeugen.

Build-Verantwortliche: Einen eigenen und eindeutigen Ergebnis-Pfad setzen

Der Parameter -resultBundlePath gibt an, an welchem Pfad das Testergebnis-Paket abgelegt werden soll. Der Pfad sollte außerhalb der versionierten Quelldateien liegen und darf nicht auf eine bereits vorhandene Datei oder ein Ergebnis eines anderen parallelen Auftrags zeigen. So können Sie nach dem Lauf eindeutig feststellen, welches Paket zu welchem Testauftrag gehört. Die Option ist in Apples Dokumentation zu den Xcode-Kommandozeilenwerkzeugen beschrieben (Referenz zu xcodebuild).

Ein Muster mit Platzhaltern sieht so aus:

RESULT_BUNDLE="<absoluter-pfad>/<auftragskennung>.xcresult"

xcodebuild test \
  -scheme "<scheme>" \
  -destination "<testziel>" \
  -resultBundlePath "$RESULT_BUNDLE"

Ersetzen Sie die Platzhalter durch die Scheme-Auswahl, das Testziel und einen Pfad, der für Ihren Runner beschreibbar ist. Verwenden Sie für parallele Testaufträge getrennte Verzeichnisse oder Namen. Andernfalls können zwei Prozesse versuchen, denselben Ergebnispfad zu verwenden; dann ist die Zuordnung unsicher, oder ein Lauf kann beim Anlegen des Pakets scheitern. Verlassen Sie sich nicht darauf, dass ein beliebiger temporärer Dateiname über die gesamte Pipeline hinweg eindeutig bleibt.

Geben Sie den Wert so weiter, dass sowohl der Testschritt als auch der Upload-Schritt denselben Pfad verwenden. Häufige Ursachen für „Datei nicht gefunden“ sind voneinander abweichende Verzeichnisvariablen, relative Pfade mit unterschiedlichem Arbeitsverzeichnis und ein Upload-Muster, das nur eine Datei statt des Ergebnisverzeichnisses auswählt. Prüfen Sie im Jobprotokoll den aufgelösten Pfad und kontrollieren Sie, ob das Verzeichnis nach dem Test tatsächlich existiert.

Für die Diagnose ist die Unterscheidung zwischen Pfadfehler und Testfehler wichtig: Ein fehlgeschlagener Test kann ein gültiges Paket hinterlassen; ein ungültiger oder kollidierender Ergebnispfad kann dagegen verhindern, dass ein verwertbares Paket entsteht. Verändern Sie daher nicht vorschnell den Upload-Schritt, wenn der Fehler bereits beim Anlegen des Ergebnis-Pakets liegt.

Workflow-Verantwortliche: Den Upload auch nach einem Testfehler ausführen

In vielen CI-Abläufen endet der Testschritt mit einem Fehlerstatus, sobald ein Test fehlschlägt. Ein nachfolgender Upload-Schritt mit den üblichen Ausführungsbedingungen kann dann übersprungen werden. Damit ist das diagnostisch wertvolle Ergebnis-Paket gerade in dem Lauf nicht verfügbar, in dem Sie es am dringendsten benötigen. GitHub Actions dokumentiert Bedingungen und Ausdrücke für Workflow-Schritte; steuern Sie damit ausdrücklich, wann der Upload trotz eines fehlgeschlagenen vorherigen Schritts laufen soll (GitHub Actions: Ausdrücke und Bedingungen).

Ein vereinfachtes Muster:

- name: Xcode-Tests ausführen
  run: |
    xcodebuild test \
      -scheme "<scheme>" \
      -destination "<testziel>" \
      -resultBundlePath "$RESULT_BUNDLE"

- name: Testergebnis-Paket hochladen
  if: ${{ always() }}
  uses: actions/upload-artifact@<freigegebene-version>
  with:
    name: "xcresult-${{ github.run_id }}-${{ github.run_attempt }}"
    path: ${{ env.RESULT_BUNDLE }}
    if-no-files-found: error

Das Beispiel zeigt die entscheidende Verbindung: Test und Upload müssen denselben Ergebnispfad verwenden, und die Bedingung des Upload-Schritts muss einen vorherigen Fehler berücksichtigen. Passen Sie die Bedingung an Ihre Abbruch- und Bereinigungsregeln an. always() kann auch nach einem Abbruch ausgeführt werden; wenn ein abgebrochener Lauf keinen Upload mehr ausführen soll, wählen Sie eine dafür passende Bedingung und testen Sie deren Verhalten. Die Ausdrucksreferenz von GitHub Actions beschreibt die verfügbaren Statusprüfungen (Dokumentation zu Workflow-Ausdrücken).

Für ein xcresult müssen Sie den Verzeichnispfad auswählen, nicht ein vermeintliches Einzelprotokoll innerhalb des Pakets. GitHub Actions unterstützt Workflow-Artefakte zum Speichern und späteren Abrufen von Build- und Testausgaben; die Konfiguration des Uploads bestimmt, welche Dateien beziehungsweise Verzeichnisse einbezogen werden (GitHub-Dokumentation zum Speichern von Workflow-Daten mit Artefakten). Bei mehreren Pfaden oder Mustern kontrollieren Sie besonders, ob die Auswahl das ganze Paket umfasst und wie die Verzeichnisstruktur im Artefakt abgebildet wird.

Verwechseln Sie Artefakte nicht mit einem Cache. Ein Cache dient der Wiederverwendung von Dateien für spätere Arbeitsabläufe; er ist kein Ersatz für ein benanntes Testergebnis, das ein Team gezielt herunterladen und prüfen soll. GitHub beschreibt Zweck und Verwaltung von Workflow-Artefakten gesondert (GitHub-Erklärung zu Workflow-Artefakten). Legen Sie in Ihrem Ablauf fest, ob der Upload bei fehlendem Pfad fehlschlagen soll. Ein sichtbarer Fehler verhindert, dass ein Lauf scheinbar erfolgreich abgeschlossen wird, obwohl gar kein Ergebnis gesichert wurde.

Testingenieure: Das heruntergeladene Paket wirklich öffnen

Ein sichtbarer Artefaktname beweist nur, dass die Plattform einen Upload registriert hat. Er beweist nicht, dass das richtige Ergebnis zum richtigen Testlauf gehört oder dass das Paket lesbar ist. Laden Sie das Artefakt über die jeweilige Workflow-Ausführung herunter. GitHub dokumentiert den Download über die Oberfläche der Workflow-Läufe (Anleitung zum Herunterladen von Workflow-Artefakten).

Nach dem Download prüfen Sie zunächst, ob die Verzeichnisstruktur und der Name zu Ihrem Upload-Muster passen. Öffnen Sie das .xcresult-Paket mit Xcode oder untersuchen Sie es in einer macOS-Umgebung mit xcresulttool. Apple nennt xcresulttool als Kommandozeilenwerkzeug für die Arbeit mit Ergebnis-Paketen; die konkreten Unterbefehle sollten Sie gegen die installierte Xcode-Version prüfen (Apple-Informationen zu Xcode 11 und den Ergebnis-Paketen).

Sie können die lokale Hilfe der installierten Werkzeugversion heranziehen:

xcrun xcresulttool --help

Für eine konkrete Auswertung hängt der passende Unterbefehl von der Xcode-Version und davon ab, welche Information Sie benötigen. Verwenden Sie daher keinen ungeprüften Befehl aus einem älteren Skript als allgemeingültige Schnittstelle. Apple beschreibt sowohl die Interpretation von Testergebnissen in Xcode als auch den Zugang über Kommandozeilenwerkzeuge; vergleichen Sie die angezeigten Informationen mit dem Fehler, den Ihr Team untersuchen soll.

Prüfen Sie mindestens, ob das Paket dem erwarteten Testlauf zugeordnet ist, ob die Zusammenfassung den fehlgeschlagenen Test erkennen lässt und ob die für Ihr Projekt benötigten Protokolle oder Anhänge vorhanden sind. Wenn Sie Abdeckungsdaten als Teil Ihrer Diagnose oder Qualitätskontrolle benötigen, kontrollieren Sie ausdrücklich, ob sie für diesen Lauf erzeugt und im heruntergeladenen Paket verfügbar sind. Gehen Sie nicht davon aus, dass jeder Testaufruf dieselben Anhänge oder dieselben Auswertungsdaten enthält.

Plattformverantwortliche: Namen, Aufbewahrung und Zugriff nachvollziehbar regeln

Der Artefaktname sollte die Zuordnung zu Workflow-Ausführung und Wiederholung ermöglichen. Verwenden Sie dafür die im Workflow verfügbaren Lauf- und Wiederholungskennungen sowie eine verständliche Bezeichnung für Scheme oder Testaufgabe. Der Beispielname im Workflow nutzt github.run_id und github.run_attempt; diese Werte sind GitHub-Kontextinformationen, keine von Xcode erzeugten Paketdaten. So lässt sich ein heruntergeladenes Ergebnis besser dem CI-Protokoll zuordnen.

Halten Sie den Namen außerdem unabhängig vom Branch-Namen, wenn Branches Sonderzeichen enthalten oder häufig umbenannt werden. Der Dateipfad kann eine Aufgabenerkennung enthalten, sollte aber nicht ungeprüft vertrauliche Informationen wie Kundennamen oder interne Ticketinhalte offenlegen. Entscheidend ist, dass Ihre Teammitglieder die Verbindung zwischen Testlauf, Commit und Artefakt nachvollziehen können, ohne dass der Name selbst unnötige Projektdetails preisgibt.

Die Aufbewahrungsfrist ist eine Richtlinienentscheidung: Legen Sie sie nach Ihren Diagnoseanforderungen und den Einstellungen Ihrer Organisation beziehungsweise Ihres Repositorys fest. Übernehmen Sie keine vermeintliche Standardfrist aus einem Beispiel, denn die effektive Verfügbarkeit hängt von der Plattformkonfiguration und den geltenden Richtlinien ab. Prüfen Sie die aktuellen Angaben in der GitHub-Dokumentation zu Workflow-Artefakten, bevor Sie eine Teamregel formulieren (Verwaltung und Speicherung von Workflow-Artefakten).

Auch die Zugriffsgrenze verdient eine eigene Prüfung. Ein Ergebnis-Paket kann Fehlermeldungen, Testdaten, Protokolle, Dateipfade oder projektspezifische Anhänge enthalten. Behandeln Sie es deshalb mindestens so sorgfältig wie andere Build-Ausgaben, begrenzen Sie den Zugriff auf den benötigten Personenkreis und vermeiden Sie einen öffentlichen Download, wenn das Paket interne Details enthält. Bei Projekten mit personenbezogenen oder anderweitig geschützten Daten müssen Sie zusätzlich die für Ihr Team geltenden Datenschutz- und DSGVO-Regeln berücksichtigen.

CI-Verantwortliche: Mit einer Erfolgs- und einer Fehlerprobe abnehmen

Bevor Sie die Pipeline als zuverlässig einstufen, führen Sie zwei kontrollierte Prüfungen durch: einen Lauf mit bestandenen Tests und einen Lauf, bei dem ein bekannter Test fehlschlägt. Die Fehlerprobe muss so gewählt sein, dass Sie sie sicher wieder entfernen können und sie keine Veröffentlichung oder nachgelagerte Bereitstellung auslöst. Der Zweck ist nicht, ein Produktivproblem zu simulieren, sondern den vollständigen Weg des Diagnoseartefakts zu belegen.

Gehen Sie anschließend in dieser Reihenfolge vor:

1. Kontrollieren Sie im Workflow-Protokoll, ob tatsächlich xcodebuild test und nicht nur ein Build ausgeführt wurde.
2. Prüfen Sie, ob der aufgelöste Wert von -resultBundlePath für diesen Auftrag eindeutig und beschreibbar ist.
3. Bestätigen Sie, dass das Ergebnisverzeichnis nach dem Testschritt vorhanden ist.
4. Prüfen Sie im fehlgeschlagenen Lauf, ob der Upload-Schritt aufgrund seiner Bedingung gestartet wurde.
5. Laden Sie das Artefakt aus der betreffenden Workflow-Ausführung herunter und öffnen Sie es auf einem Mac.
6. Vergleichen Sie den darin erkennbaren Testfehler mit dem erwarteten Fehler und prüfen Sie benötigte Protokolle oder Abdeckungsdaten.
7. Wiederholen Sie den Download nach Ablauf der für das Projekt festgelegten Frist, falls Ihr Abnahmeverfahren auch die Aufbewahrungsrichtlinie kontrolliert.

Nutzen Sie die Belege zur Eingrenzung, statt mehrere Einstellungen gleichzeitig zu ändern. Wenn kein Verzeichnis erzeugt wurde, prüfen Sie zuerst Testaufruf und Ergebnispfad. Wenn das Verzeichnis vorhanden ist, aber kein Artefakt auftaucht, untersuchen Sie Bedingung, Upload-Pfad und Schrittprotokoll. Wenn das Artefakt da ist, aber das Paket fehlt oder unvollständig wirkt, kontrollieren Sie die Dateiauswahl und den tatsächlichen Inhalt des Downloads. Wenn der Download nach einer gewissen Zeit nicht mehr verfügbar ist, prüfen Sie die Aufbewahrungs- und Zugriffsregeln, statt den Fehler dem Xcode-Test zuzuschreiben.

Entscheidung nach Ergebnis: Pipeline ändern oder den Mac-Ausführungspfad prüfen

• Wenn xcodebuild test kein Ergebnisverzeichnis erzeugt, korrigieren Sie zuerst den Testaufruf oder den -resultBundlePath; ein zusätzlicher Upload-Schritt kann ein nicht erzeugtes Paket nicht retten.
• Wenn das Paket vorhanden ist, aber der Upload nach einem Testfehler fehlt, passen Sie die Schrittbedingung an und wiederholen Sie gezielt die Fehlerprobe.
• Wenn ein Artefakt hochgeladen wurde, der Download aber nicht das vollständige Paket enthält, korrigieren Sie Pfadmuster und Verzeichniszuordnung.
• Wenn das Paket heruntergeladen, aber nicht lesbar ist, prüfen Sie die Xcode- und Werkzeugversion sowie die Unversehrtheit des Downloads, bevor Sie die Pipeline als abgenommen markieren.
• Wenn das Paket nur für einen begrenzten Zeitraum gebraucht wird, reicht eine passende Artefaktregel; verlangen interne Richtlinien eine längere oder anders kontrollierte Ablage, müssen Sie dafür eine dafür freigegebene Speicherlösung planen.

Für den Betrieb einer Mac-gestützten CI-Umgebung sollten Sie zusätzlich klären, ob der Ausführungsknoten zu Ihren Build-Zeiten und Wartungsabläufen passt. Einen Überblick über die verfügbaren Remote-Mac-Angebote finden Sie in der VPSMAC-Übersicht; bei einer konkreten Auswahl können Sie die Informationen zum M4-Knoten als Ausgangspunkt prüfen.

Ein Linux-CI-Host kann viele allgemeine Aufgaben erledigen, aber keine macOS-spezifischen Xcode-Tests ausführen. Ein eigener Mac bietet direkte Hardwarekontrolle und kann für dauerhaft ausgelastete, langfristig stabile Builds sinnvoll sein, bindet jedoch Kapital und muss von Ihnen selbst betrieben werden. Wenn Sie nur zeitweise einen echten Mac für Tests oder einen zusätzlichen CI-Ausführungspfad benötigen, kann die Miete über VPSMAC diese Anschaffung und einen Teil des laufenden Hardwarebetriebs vermeiden; prüfen Sie vor der Entscheidung trotzdem Zugriff, Datenschutz, Wartungsverantwortung und die tatsächliche Erreichbarkeit Ihrer Artefakte.