## 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
2.5 KiB
| title | date-modified | tags | |||
|---|---|---|---|---|---|
| Gandi | 2026-02-08 |
|
Gandi
DNS hosting provider for the eblu.me domain, managed via Pulumi IaC.
Quick Reference
| Property | Value |
|---|---|
| Domain | eblu.me |
| Provider | Gandi LiveDNS |
| IaC | pulumi/gandi/ |
| Stack | eblu-me |
What It Does
Gandi hosts the DNS records that make *.ops.eblu.me resolve to indri's Tailscale IP (indri.tail8d86e.ts.net). Since Tailscale IPs are not publicly routable, this gives services real DNS names while keeping them private to the tailnet.
The target IP is resolved dynamically from indri.tail8d86e.ts.net at deploy time, so if indri's Tailscale IP changes, re-running the deployment is sufficient.
DNS Records
Private services (Caddy on indri)
| Record | Type | Value | TTL |
|---|---|---|---|
*.ops.eblu.me |
A | indri's Tailscale IP | 300s |
ops.eblu.me |
A | indri's Tailscale IP | 300s |
Both records point to indri, which runs caddy as the reverse proxy for all private services.
Public services (Fly.io proxy)
| Record | Type | Value | TTL |
|---|---|---|---|
docs.eblu.me |
CNAME | blumeops-proxy.fly.dev |
300s |
Public CNAMEs point to flyio-proxy on Fly.io. See expose-service-publicly for adding new public services.
See routing for the full service URL map.
Pulumi Configuration
The Pulumi program lives in pulumi/gandi/:
__main__.py- Creates the two A records viapulumiverse_gandiPulumi.eblu-me.yaml- Stack config (domain, subdomain)
Stack config values:
| Key | Value |
|---|---|
blumeops-dns:domain |
eblu.me |
blumeops-dns:subdomain |
ops |
A break-glass override is available via the BLUMEOPS_REVERSE_PROXY_IP environment variable, which bypasses dynamic IP resolution.
TLS Integration
caddy uses Gandi's API separately (via GANDI_BEARER_TOKEN) for ACME DNS-01 challenges to obtain a wildcard Let's Encrypt certificate for *.ops.eblu.me. This is a different credential from the Pulumi PAT.
Authentication
Gandi requires a Personal Access Token (PAT) for API access. PATs have a maximum lifetime of 90 days (currently set to 30). See gandi-operations for deployment and PAT cycling instructions.
Related
- gandi-operations - PAT cycling and deployment how-to
- routing - Service URLs and routing architecture
- caddy - Reverse proxy using Gandi for TLS
- tailscale - Tailnet networking
- indri - Server hosting Caddy (DNS target)