Fehlerbehebung in unserer CI/CD-Pipeline: Submodule, leere Commits und das QA-Gate

Unsere Website-Pipeline hatte ein wiederkehrendes Problem: Bereitstellungen, die lokal funktionierten, schlugen in GitHub Actions lautlos fehl oder waren in Actions erfolgreich, produzierten aber eine fehlerhafte Website. Hier ist die Ursachenanalyse und was wir geändert haben.

Die drei Fehlermodi

1. Build erfolgreich, Website-Inhalt fehlt — das Ausgabeverzeichnis wurde generiert, aber der Git-Commit-Schritt schlug lautlos fehl, weil es nichts Neues zu committen gab. Der Bereitstellungsschritt lief trotzdem und übertrug einen veralteten Build.
2. Theme-Submodul nicht initialisiert — das Theme ist ein Git-Submodul. Frische Actions-Runner klonen das Repo, initialisieren Submodule aber nicht automatisch. Der Build lief mit leerem Theme-Verzeichnis und erzeugte einen ungestylten Build, der dennoch mit Code 0 endete.
3. Verzögerung bei der Cache-Invalidierung — über das CDN zwischengespeicherte Seiten lieferten nach einer neuen Bereitstellung veraltete Inhalte.

Fix 1: Submodul-Initialisierung

- uses: actions/checkout@v4
  with:
    submodules: true        # ← dies fehlte
    fetch-depth: 0

Ohne submodules: true findet der Build die Theme-Referenz, sucht im Theme-Verzeichnis, findet nichts und greift auf Standard-Templates zurück — komplett ungestylt.

Fix 2: Der Schutz vor leeren Commits

# Vorher — committet immer, schlägt fehl, wenn sich nichts geändert hat
git add public/
git commit -m "Deploy"
git push

# Nachher — überspringt, wenn sich nichts geändert hat
git add public/
git diff --staged --quiet || git commit -m "chore: deploy $(date -u +%Y-%m-%dT%H:%M:%SZ)"
git push

git diff --staged --quiet endet mit 0 (keine Änderungen) → Commit überspringen. Endet ungleich Null (Änderungen vorhanden) → Commit und Push.

Das automatisierte QA-Gate

Um diese Fehler ohne manuelle Prüfung abzufangen, haben wir einen Verifizierungsschritt in die Pipeline eingebaut:

1. Ruft die URL der Live-Site nach einer Bereitstellung ab
2. Prüft, ob der Titel des neuesten Beitrags im HTML vorhanden ist
3. Prüft, ob der Last-Modified-Header neuer ist als der vorherige Bereitstellungszeitpunkt
4. Lässt die Pipeline fehlschlagen, wenn eine Prüfung nicht besteht

Das verwandelt die Bereitstellungsprüfung von einem manuellen Check in ein automatisiertes Gate.

---

Historische Notiz: Diese Analyse betrifft die stillgelegte Hugo-Pipeline. Die Website nutzt inzwischen ein Direkt-Bereitstellungsmodell.