04
Übergabe und Xcode-Prüfung: Ergebnisse nicht miteinander verwechseln
Wie kann die Codex GitHub Action an Xcode-Builds und Tests beteiligt werden? Indem sie einen abgegrenzten Arbeitsschritt übernimmt und das Ergebnis an einen eigenständigen Prüfpunkt übergibt. Bei einer Analyse kann das Ergebnis ein Review-Bericht sein; bei einer kontrollierten Änderung kann es ein prüfbarer Diff sein. Der nachfolgende Mac-Job entscheidet anhand des tatsächlichen Build- und Testergebnisses, ob die Änderung technisch akzeptiert werden kann.
Dazu gehört, fünf Arten von Ergebnissen getrennt zu halten:
- Agent-Ausgabe: Vorschlag, Zusammenfassung oder Prüfergebnis des Agenten.
- Arbeitsbereichsänderung: Der konkrete Diff, den ein Mensch oder ein kontrollierter Folgejob prüfen kann.
- Build-Ergebnis: Der Exit-Status des tatsächlichen
xcodebuild-Aufrufs.
- Testergebnis: Die vom Testlauf erzeugten Resultate und Diagnosedaten.
- Signaturartefakt: Ein Ergebnis, das erst in einem ausdrücklich berechtigten Schritt erstellt wird.
Eine Nachricht wie „Änderung sieht korrekt aus“ ist kein Ersatz für einen erfolgreichen Build. Ein erfolgreicher Build beweist seinerseits nicht, dass alle erforderlichen Tests bestanden wurden oder dass ein Signaturartefakt freigegeben ist. Legen Sie im Workflow daher getrennte Bedingungen fest: Der Mac-Job läuft nur dann, wenn die vorgesehene Übergabe vorhanden ist; eine Freigabe verlangt zusätzlich die für Ihr Projekt definierten Review- und Testnachweise.
GitHub Actions kann Ergebnisse zwischen Jobs als Artefakte bereitstellen. Nutzen Sie diese Funktion so, dass ein Folgejob die benötigten Dateien erhält, aber nicht ungeprüfte Inhalte automatisch als ausführbaren Code behandelt. Die offizielle Anleitung zum Speichern und Teilen von Workflow-Daten beschreibt den Artefaktfluss; prüfen Sie außerdem, welche Rechte das Herunterladen und die weitere Verarbeitung in Ihrem Workflow erfordern.
Erfahrungshinweis: Ein gespeicherter Diff lässt sich vor dem Build prüfen. Ein Agent-Text allein ist dagegen schwerer als reproduzierbarer Nachweis zu behandeln, wenn nicht klar festgehalten wird, auf welchen Commit und welchen Arbeitsstand er sich bezieht.
Für den ersten Mac-Test sollten Sie eine Projektkonfiguration wählen, die tatsächlich zu Ihrem Vorhaben passt: vorgesehenes Scheme, geeignete Destination, passende Abhängigkeiten und die vom Projekt erwartete Xcode-Umgebung. Ein schematischer Aufruf kann so aussehen:
xcodebuild \
-scheme "<SCHEME>" \
-destination "<ZIEL>" \
test
Ersetzen Sie beide Platzhalter durch Werte aus Ihrem Projekt und Workflow. Dokumentieren Sie den Aufruf und speichern Sie die relevanten Ergebnisse so, dass ein fehlgeschlagener Test später nachvollzogen werden kann. Apple beschreibt, wie Testergebnisse ausgeführt und interpretiert werden, in der Xcode-Dokumentation zu Tests und Testergebnissen. Welche Ergebnisdateien und Diagnosen für die Abnahme nötig sind, sollten Sie aus dem Projekt und Apples Dokumentation ableiten, nicht aus einer Agent-Zusammenfassung.
Damit beantworten Sie auch die Frage, ob Codex Agent und xcodebuild in denselben CI-Job gehören. Für einen ersten Rollout in der Regel nicht: getrennte Jobs ermöglichen einen klareren Übergabepunkt und erlauben, Agent-Rechte von Mac-Ausführung und Signierung zu unterscheiden. Ein gemeinsamer Job kann für einen begrenzten internen Versuch vertretbar sein, wenn er ohne Produktionsgeheimnisse läuft, der Trigger vertrauenswürdig ist und der Runner entsprechend isoliert wird. Er sollte nicht aus Bequemlichkeit zur Release-Architektur werden.
