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

4.1 KiB

Raw Blame History

title

date-modified

Your First Contribution

Audiences: Contributor

This tutorial walks through making your first contribution to BluemeOps - from understanding the codebase to submitting a pull request.

Prerequisites

Before contributing, you'll need:

Access to the tailscale network (request from Erich)
SSH key added to forgejo (https://forge.ops.eblu.me)
Development tools installed (see below)

Tooling Setup

The repo includes a Brewfile and mise.toml for easy setup, but these are optional - install the tools however you prefer.

Required Tools

tea - Gitea/Forgejo CLI for creating PRs
argocd - ArgoCD CLI for deployments
pre-commit - Git hooks for validation

Using Brewfile (Optional)

brew bundle  # installs tea, argocd, mise, etc.

Using Mise (Optional)

Mise manages language toolchains and runs tasks:

mise install  # installs Python, Node.js, etc. from mise.toml

Pre-commit Hooks

Pre-commit hooks validate changes on git commit:

pre-commit install
pre-commit run --all-files  # verify setup

All hooks should pass on a fresh clone.

Understanding the Codebase

BlumeOps manages infrastructure through three main systems:

System	Directory	What It Manages
Ansible	`ansible/`	Services running directly on indri
ArgoCD	`argocd/`	Kubernetes services in the cluster
Pulumi	`pulumi/`	[[tailscale

Most contributions involve either Ansible roles or ArgoCD manifests.

The Contribution Workflow

1. Clone and Branch

git clone ssh://git@forge.ops.eblu.me:2222/eblume/blumeops.git
cd blumeops
git checkout -b feature/your-change-name

2. Make Your Changes

Depending on what you're changing:

For Kubernetes services:

Edit manifests in argocd/manifests/<service>/
Or create new Application in argocd/apps/
For new apps, set targetRevision to your feature branch for testing
For existing apps, you'll need to temporarily change the revision via argocd app set

For Indri services:

Edit or create roles in ansible/roles/
Update ansible/playbooks/indri.yml if adding a role

For documentation:

Edit files in docs/
Add changelog fragment (see below)

3. Add a Changelog Fragment

For user-visible changes:

echo "Description of your change" > docs/changelog.d/your-branch.feature.md

Fragment types (file suffix):

.feature.md - New functionality
.bugfix.md - Bug fixes
.infra.md - Infrastructure changes
.doc.md - Documentation
.misc.md - Other

4. Test Your Changes

Before pushing, always test:

For Kubernetes changes:

# Preview what will change
argocd app diff <service>

For DNS changes:

mise run dns-preview

5. Commit and Push

git add <files>
git commit -m "Brief description of change"
git push -u origin feature/your-change-name

6. Create a Pull Request

tea pr create --title "Your PR Title" --description "$(cat <<'EOF'
## Summary
- What you changed
- Why you changed it

## Deployment and Testing
- [ ] Tested locally / dry run
- [ ] Ready for ArgoCD sync / Ansible apply

EOF
)"

7. Wait for Review

Erich will review your PR and may leave comments. Check for feedback:

mise run pr-comments <pr_number>

Address each comment, then Erich will:

Approve the changes
Deploy them (you don't need to do this)
Merge the PR

Example: Adding a Homepage Link

A simple first contribution - adding a service to the Homepage dashboard (go.ops.eblu.me):

Find the service's Ingress in argocd/manifests/<service>/
Add homepage annotations:

annotations:
  gethomepage.dev/enabled: "true"
  gethomepage.dev/name: "Service Name"
  gethomepage.dev/group: "Apps"
  gethomepage.dev/icon: "service.png"

Create PR and wait for sync

adding-a-service - Full tutorial on deploying a new service
replicating-blumeops - If you want to build your own instead

4.1 KiB Raw Blame History