Ein Beitrag pro Tag aus einem Cronjob

Christian Drexler

Eine meiner Seiten veröffentlicht seit Mitte September jeden Morgen um 07:40 einen Artikel. Niemand schreibt ihn an dem Tag. Die Form passt in einen Absatz, und das Interessante sind die kleinen Entscheidungen drumherum.

Die Form

Ein Ordner enthält Rohmaterial: Notizen, Briefings, Produktblätter, alte Entwürfe, jedes als Datei. Ein Job läuft einmal am Tag. Er nimmt die älteste Datei, die noch nicht verwendet wurde, schreibt daraus mit einem Sprachmodell einen Artikel, baut die statische Seite, committet und pusht. Der Host deployt beim Push. Ins Log kommt pro Lauf eine Zeile: [posted] <slug> oder [skipped] <grund>.

40 7 * * *  /usr/bin/flock -n /tmp/daily.lock  /home/me/daily/run.sh >> /home/me/daily/run.log 2>&1

Das flock ist wichtiger, als es aussieht. Wenn der gestrige Lauf an einem Netzwerkaufruf hängt, willst du nicht, dass der heutige obendrauf startet und doppelt veröffentlicht.

Verbraucht heißt verbraucht

Der Job markiert eine Quelldatei als verbraucht, indem er sie in einen Ordner done/ verschiebt, nicht indem er irgendwo eine Liste führt. Eine Liste kann vom Ordner abweichen; der Ordner kann nicht von sich selbst abweichen. Ist der Quellordner leer, schreibt der Job [skipped] no source und beendet sich mit Exit 0. Ein leerer Eingang ist kein Fehler, sondern das Signal, dass ich Material nachlegen muss, und die Logzeile reicht als Erinnerung.

Idempotent nach Datum

Bevor der Job irgendetwas tut, prüft er, ob schon ein Beitrag mit dem heutigen Datum existiert. Wenn ja, beendet er sich. Diese eine Prüfung bedeutet, dass ich das Skript zu jeder Uhrzeit von Hand starten kann, um es zu testen, oder nach einer Korrektur erneut anstoßen kann, ohne je einen zweiten Beitrag für den Tag zu erzeugen. Die meisten "der Cron hat zweimal gefeuert"-Probleme verschwinden, sobald der Job sich weigert, sich zu wiederholen.

Die Woche mit Mensch

In den ersten sieben Tagen habe ich jeden Beitrag gelesen, bevor er live ging. Der Job schrieb auf einen Staging-Branch, ich las den Entwurf beim Kaffee auf dem Handy und habe gemergt oder verworfen. Drei flogen raus: einer, weil er nichts sagte, einer wegen einer Behauptung, die die Quelle nicht hergab, einer wegen eines Tons, der die Seite blamiert hätte. Jede Ablehnung hat den Prompt verändert oder dem Schreibschritt eine Regel hinzugefügt. Nach der Woche wechselte der Job auf den Hauptbranch, und ich habe aufgehört, täglich zu lesen.

Einmal pro Woche überfliege ich noch. Im Prompt steht inzwischen eine Zeile, die sagt: Wenn die Quelle nicht genug hergibt, verweigern und [skipped] thin source loggen. Die Zeile stammt aus den abgelehnten Beiträgen.

Worauf ich achten würde

Ein Build-Fehler nach dem Schreiben hinterlässt einen committeten, aber nicht veröffentlichten Entwurf; das Log sagt [posted], die Seite zeigt nichts. Die Lösung: erst loggen, wenn die Deploy-Prüfung durch ist, und als letzten Schritt die neue URL abrufen. Außerdem: Das Datum, das das Modell für heute hält, ist das, was du ihm sagst. Gib es explizit mit, statt es raten zu lassen.

Nichts davon ist schlau. Es ist ein Job, ein Ordner, ein Log und eine Woche Lesen, bevor du vertraust. Diese Woche ist der Teil, den die meisten auslassen.