Complete the automated release process for the CLI, picking up where DCP-2422 left off.
Current State
Conventional commits enforcement and local changelog tooling are in place (PRs #321, #322). A full release automation workflow was built and merged (#322) but had to be rolled back (#340) due to CI permissions constraints.
The release process is currently manual: a developer must run make changelog, draft a GitHub Release in the UI, create a tag, and publish to trigger binary builds.
What's Needed
Automate the release process so that a release can be triggered with minimal manual steps, handling: version calculation from conventional commits, changelog generation via git-cliff, tagging, and GitHub Release creation — triggering existing binary/Docker build workflows.
Ideal: Single-action release
One workflow dispatch (choosing patch/minor/major) handles everything end-to-end.
Acceptable: Two-step release
- Generate changelog — run
make changelog VERSION=x.y.z locally or via CI to update CHANGELOG.md and commit
- Trigger release workflow — dispatch a workflow that reads the latest changelog entry, creates a git tag, publishes a GitHub Release, and triggers binary/Docker builds
The two-step approach avoids the CI permissions complexity of creating PRs/commits from workflows while still eliminating the manual GitHub Releases UI work.
Prior Art
Complete the automated release process for the CLI, picking up where DCP-2422 left off.
Current State
Conventional commits enforcement and local changelog tooling are in place (PRs #321, #322). A full release automation workflow was built and merged (#322) but had to be rolled back (#340) due to CI permissions constraints.
The release process is currently manual: a developer must run
make changelog, draft a GitHub Release in the UI, create a tag, and publish to trigger binary builds.What's Needed
Automate the release process so that a release can be triggered with minimal manual steps, handling: version calculation from conventional commits, changelog generation via git-cliff, tagging, and GitHub Release creation — triggering existing binary/Docker build workflows.
Ideal: Single-action release
One workflow dispatch (choosing patch/minor/major) handles everything end-to-end.
Acceptable: Two-step release
make changelog VERSION=x.y.zlocally or via CI to updateCHANGELOG.mdand commitThe two-step approach avoids the CI permissions complexity of creating PRs/commits from workflows while still eliminating the manual GitHub Releases UI work.
Prior Art
cliff.tomlandscripts/changelog/— already in the codebase and working