Erich Blume
b197bd5f58
## Summary Migrates the docs build pipeline to Dagger (Phase 2 of the Dagger CI adoption plan). - **Backfill `date-modified` frontmatter** on all 80 docs — Dagger's `--src=.` excludes `.git`, so Quartz can't use git history for page dates. Frontmatter dates work with or without git. - **New `docs-check-frontmatter` mise task + pre-commit hook** — validates all docs have `title`, `tags`, and `date-modified` - **New Dagger functions** — `build_changelog` (towncrier in Python container) and `build_docs` (chains changelog → Quartz build in Node container, returns tarball) - **Simplified CI workflow** — the ~44-line inline Quartz build (clone, npm ci, build, tar, cleanup) is replaced by `dagger call build-docs`. Changelog step remains local on the runner since towncrier needs to modify the host working tree for the git commit. ### Design decisions - **Towncrier runs twice in CI**: once inside Dagger (for the docs tarball) and once on the runner (for the git commit). This is intentional — Dagger's directory export is additive and can't delete the consumed changelog fragments from the host. - **Artifact hosting stays on Forgejo Releases** (not migrated to Forgejo Packages as the plan doc originally suggested). That migration can happen independently. - **`date-modified` frontmatter** preserved even though `build_changelog` installs git — the git there is only for towncrier's `git add` call, not for history. The local iteration story (`dagger call build-docs --src=. --version=dev` with uncommitted changes) depends on frontmatter dates. ### Local iteration ```bash dagger call build-docs --src=. --version=dev export --path=./docs-dev.tar.gz tar tf docs-dev.tar.gz | head -20 ``` ## Deployment and Testing - [x] `dagger call build-docs --src=. --version=dev` produces valid 1.1MB tarball (149 HTML pages) - [x] Pre-commit hooks pass (including new `docs-check-frontmatter`) - [ ] Full `workflow_dispatch` run after merge 🤖 Generated with [Claude Code](https://claude.com/claude-code) Reviewed-on: https://forge.ops.eblu.me/eblume/blumeops/pulls/157
1.9 KiB
| title | date-modified | aliases | id | tags |
|---|---|---|---|---|
| BlumeOps | 2026-02-08 | index |
Welcome to the BlumeOps (aka "Blue Mops") documentation. Here you will find hopefully everything you'll need to understand and operate my personal digital infrastructure.
New here? Start with exploring-the-docs to find your way around.
What is BlumeOps?
BlumeOps is my personal homelab infrastructure managed entirely through code. Everything lives in a single git repository, from service configs to deployment automation. Even the forgejo instance that hosts this repo is defined within it, making BlumeOps fully self-hosting. It's a digital life raft I built for myself as I went, and you can see it all from within your editor of choice. (I recommend vim.)
These services run on my home hosts, primarily an m1 mac
mini named indri and a Synology NAS called sifaka. The infrastructure
is networked via tailscale, with the domain eblu.me hosted via gandi,
caddy providing a private reverse proxy for tailnet devices, and
flyio-proxy serving public-facing services like
this documentation site.
The goal of BlumeOps is threefold:
- To provide a rich array of useful personal services in order to manage my own digital life.
- To exercise my skills as a software engineer specializing in Platforms/DevOps/SRE.
- To act as a portfolio piece for talking about building hosted software platforms.
Sections
- tutorials - Learning-oriented guides for getting started
- reference - Technical specifications and service details
- how-to - Task-oriented instructions for common operations
- explanation - Understanding the "why" behind BlumeOps
- CHANGELOG - Release history and changes