Das Journal, das sich von selbst schreibt

Jede sinnvolle Änderung in meinem Homelab schreibt ein Event in ein Ledger — ein Deploy, eine Konfigurationsänderung, ein Incident, eine Entscheidung. Das ist für Maschinen nützlich und für mich nahezu nutzlos, weil niemand einen Event-Stream liest.

Darauf sitzen zwei geplante Jobs. Der erste verwandelt die letzten vierundzwanzig Stunden an Events in eine geschriebene Markdown-Zusammenfassung in einem Outbox-Ordner. Der zweite veröffentlicht diese Zusammenfassung eine halbe Stunde später als einzelne Notiz in meiner Notizen-App.

Kleine Pipeline. Drei Details darin haben echten Aufwand gekostet.

Der Idempotenz-Schlüssel lebt im Artefakt

Jede Notiz endet mit einem Tagesmarker-Tag. Vor dem Veröffentlichen sucht der Job nach diesem Marker; wenn er einen findet, überspringt er das Publishing.

Die naive Alternative ist eine lokale Statusdatei, die aufzeichnet, was schon veröffentlicht wurde. Diese Version habe ich schon geschrieben, und sie ist auf eine bestimmte Weise falsch: Der Status und das, was er beschreibt, liegen an unterschiedlichen Orten, also können sie auseinanderdriften. Löscht du die Notiz, sagt die Statusdatei trotzdem „veröffentlicht“. Stellt man aus einem Backup wieder her, gibt es Duplikate. Läuft der Job auf einem zweiten Host, gibt es alles doppelt.

Den Schlüssel im veröffentlichten Artefakt zu speichern macht das Ziel zur einzigen Quelle der Wahrheit darüber, was im Ziel ist. Es gibt keine zweite Kopie, die auseinanderdriften kann.

Es schlägt „closed“ fehl

Wenn die Duplikatsprüfung selbst nicht abgeschlossen werden kann — die Notes-API ist down, die Suche schlägt fehl, die Antwort ist nicht parsebar —, dann veröffentlicht der Job nicht. Er schlägt laut fehl und schreibt nichts.

Das ist der Zweig, den die meisten solchen Skripte falsch machen, weil das verlockende Verhalten ist, anzunehmen, dass kein Duplikat gefunden wurde, und einfach weiterzumachen. Das verwandelt einen temporären Ausfall in permanenten doppelten Content, und zwar genau in dem Moment, in dem du am wenigsten hinschaust. Wenn du nicht beweisen kannst, dass du eine Sache noch nicht gemacht hast, hast du dir das Recht, sie zu tun, nicht verdient.

Das Deploy ist ein git pull, den ich vergessen habe

Diese Pipeline läuft auf einem anderen Host als dem, auf dem ich entwickle, und das Deployment ist ein git pull auf diesem Host.

Ich habe einen Tag damit verbracht, einen Fehler zu debuggen, den ich schon behoben hatte. Der Fix war auf meinem Workstation. Die Pipeline lief den vorherigen Commit, treu und genau wie befohlen. Jede Logzeile, die ich las, war wahrheitsgemäß und jede beschrieb Code, den ich nicht mehr hatte.

Die Lektion ist nicht „denk dran zu deployen“. Sie lautet, dass eine Pipeline dir sagen können sollte, welche Version von sich selbst sie gerade ausführt. Wenn die Antwort auf „Warum ist der gefixte Code noch kaputt?“ „Weil es nicht der gefixte Code ist“ lautet, willst du das in der Ausgabe sehen und nicht erst nach einem Nachmittag Herumrätseln.

Warum das Ganze

Weil ein Homelab, in dem die Arbeit unsichtbar ist, ein Homelab ist, in dem die Arbeit aufhört. Eine geschriebene tägliche Zusammenfassung, in derselben App wie der Rest meiner Notizen, bedeutet, dass das System mir an einem Ort berichtet, an dem ich sowieso schon nachsehe — und nicht in einem Dashboard, das ich erst öffnen muss.