Add plans for Dagger CI/CD and upstream fork strategy #150

Merged

eblume merged 1 commit from feature/ci-and-fork-plans into main

2026-02-11 10:20:14 -08:00

eblume commented

2026-02-11 10:19:51 -08:00

Owner

Summary

Two new plan documents in docs/how-to/plans/:

adopt-dagger-ci — Migrate CI/CD build logic from Forgejo Actions YAML to Dagger (Python SDK). Forgejo Actions stays as a thin trigger layer. Covers:
- Container builds with local iteration (dagger call build ... terminal)
- Docs builds with Forgejo packages migration (replacing Forgejo releases)
- Runner simplification (only Docker + dagger CLI needed)
- Secrets handling via Dagger's Secret type
- Future: forked project builds, Python packages, pre-merge validation
upstream-fork-strategy — Stacked-branch pattern for maintaining forks of upstream projects. Covers:
- Daily automated rebase with conflict detection and issue creation
- Branch model: upstream/main → blumeops → feature/*
- Quartz fork as first instance, enabling last-reviewed frontmatter rendering in docs
- Upstream PR path for contributing changes back

Context

These plans emerged from evaluating alternatives to the GHA ecosystem (BuildKite, Concourse, Earthly) for CI/CD. Dagger was chosen for its local iteration story, Python-native pipelines, and zero-infrastructure requirements. The fork strategy is a prerequisite for customizing Quartz and other upstream tools.

Neither plan is ready for execution yet — they are design documents for future work.

## Summary Two new plan documents in `docs/how-to/plans/`: - **adopt-dagger-ci** — Migrate CI/CD build logic from Forgejo Actions YAML to Dagger (Python SDK). Forgejo Actions stays as a thin trigger layer. Covers: - Container builds with local iteration (`dagger call build ... terminal`) - Docs builds with Forgejo packages migration (replacing Forgejo releases) - Runner simplification (only Docker + dagger CLI needed) - Secrets handling via Dagger's `Secret` type - Future: forked project builds, Python packages, pre-merge validation - **upstream-fork-strategy** — Stacked-branch pattern for maintaining forks of upstream projects. Covers: - Daily automated rebase with conflict detection and issue creation - Branch model: `upstream/main` → `blumeops` → `feature/*` - Quartz fork as first instance, enabling `last-reviewed` frontmatter rendering in docs - Upstream PR path for contributing changes back ## Context These plans emerged from evaluating alternatives to the GHA ecosystem (BuildKite, Concourse, Earthly) for CI/CD. Dagger was chosen for its local iteration story, Python-native pipelines, and zero-infrastructure requirements. The fork strategy is a prerequisite for customizing Quartz and other upstream tools. Neither plan is ready for execution yet — they are design documents for future work.

eblume added 1 commit

2026-02-11 10:19:52 -08:00

Add plans for Dagger CI/CD adoption and upstream fork strategy 4dd87371ab

Two new plan documents:
- adopt-dagger-ci: Migrate build logic to Dagger (Python SDK) with Forgejo
  Actions as thin trigger layer. Covers container builds, docs builds,
  Forgejo packages migration, and runner simplification.
- upstream-fork-strategy: Stacked-branch pattern for tracking upstream
  projects with local modifications. Quartz fork as first instance,
  enabling last-reviewed frontmatter rendering in docs.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>