Erich Blume b197bd5f58 Adopt Dagger CI for docs build (Phase 2) (#157 )

## 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

2026-02-11 16:33:16 -08:00

3.3 KiB

Raw Blame History

title

date-modified

Setting Up Tailscale

Audiences: Replicator

This tutorial walks through establishing a Tailscale mesh network as the foundation for your homelab infrastructure.

Why Tailscale?

Tailscale solves several problems at once:

Secure connectivity - WireGuard-encrypted traffic between all devices
No port forwarding - Devices connect directly through NATs and firewalls
MagicDNS - Human-readable names like server.tailnet.ts.net
ACLs - Fine-grained access control between devices

For BlumeOps context, see tailscale.

Step 1: Create Your Tailnet

Sign up at tailscale.com
Choose your identity provider (Google, Microsoft, GitHub, etc.)
Note your tailnet name (e.g., yourname.ts.net)

Step 2: Install on Your Devices

macOS

brew install tailscale
sudo tailscaled &
tailscale up

Linux

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up

Other Platforms

See Tailscale Downloads for iOS, Android, Windows, etc.

Step 3: Verify Connectivity

After installing on two devices:

tailscale status
# Shows all connected devices

ping <other-device>.yourname.ts.net
# Should work immediately

Step 4: Configure ACLs

Default Tailscale allows all-to-all connectivity. For a homelab, you'll want restrictions.

Create policy.hujson (or use the web admin):

{
  "groups": {
    "group:admin": ["your-email@example.com"]
  },
  "tagOwners": {
    "tag:homelab": ["group:admin"]
  },
  "acls": [
    // Admins can access everything
    {"action": "accept", "src": ["group:admin"], "dst": ["*:*"]},
    // Homelab servers can reach NAS
    {"action": "accept", "src": ["tag:homelab"], "dst": ["tag:nas:*"]}
  ]
}

BlumeOps manages ACLs via Pulumi - see tailscale for the actual configuration.

Step 5: Enable MagicDNS

In the Tailscale admin console:

Go to DNS settings
Enable MagicDNS
Optionally add a search domain

Now ssh server works instead of ssh 100.x.y.z.

Step 6: Tag Your Devices

Tags enable role-based access control:

# On your server
sudo tailscale up --advertise-tags=tag:homelab

Tags must be defined in ACLs before use.

What You Now Have

Encrypted mesh network between all your devices
DNS names for each device
Foundation for exposing services securely

Next Steps

With networking established:

core-services - Install Forgejo and optionally a container registry
kubernetes-bootstrap - Your cluster will join the tailnet

BlumeOps Specifics

BlumeOps' Tailscale configuration includes:

Multiple device tags (homelab, nas, registry, k8s-api)
Group-based access for family members
SSH access rules with authentication requirements

See tailscale for full details.

Troubleshooting

Problem	Solution
Device won't connect	Check firewall allows UDP 41641
Can't reach other devices	Verify ACLs don't block traffic
DNS not resolving	Enable MagicDNS in admin console
Tags not applying	Ensure tags defined in ACL policy

3.3 KiB Raw Blame History