A Git-backed publishing pipeline
This site is a directory of Markdown files. There is no database, no admin panel, and nothing to log into. A scheduled job reads the files, decides what changed, and syndicates the ones I have opted in for. Everything else is a consequence of that.
The repo is the source of truth
The rule that makes the rest of the design fall out: if it is not in the repo,
it is not published. The site build reads posts/ directly. The syndication
job reads posts/ directly. There is no third copy that can drift.
That rule has a corollary that is easy to get wrong — the pipeline has to be willing to overwrite the remote copy, which means it must never overwrite mine. So the publisher owns exactly three frontmatter keys, writes them back surgically, and verifies the result re-parses before it touches the disk.
Scheduling is just a timestamp
Every post carries a publish_at in UTC. A post whose timestamp is in the
future is excluded from the site build and skipped by the publisher, with the
remaining time logged. Publishing on Tuesday morning means writing a date, not
remembering to press a button on Tuesday morning.
Idempotence over cleverness
The publisher hashes the exact JSON body it would send. If the hash matches what it recorded last time, it does nothing. That single check is what makes an hourly cron job safe: twenty-four runs a day, one article, no duplicates.
The failure mode it is designed against is the one that actually happens — a half-finished run, a rate limit, a retry that creates a second copy of an article. Collecting failures instead of aborting, and committing the state write-back even when the run failed, are both in service of that.
What it deliberately does not do
- It does not pull from dev.to. Editing there is a one-way trip that the next
sync will overwrite, and
statusexists to make that visible before it bites. - It does not guess. A hash with no article id is a corrupt state, not a puzzle to solve, so it fails loudly.
- It does not syndicate by default. Everything lives here; dev.to is opt-in, per post, with a canonical URL pointing back.
Published . Canonical copy: https://blog.fiae.dev/hello-blog-pipeline.