dtctl Release Process (release-please)

dtctl releases use release-please but are triggered manually — nothing releases on ordinary merges to main. There is no manual version bump, no CHANGELOG.md to edit, and no tag to push by hand. The release notes and version are computed from the Conventional Commits since the last release.

How it works

The .github/workflows/release.yml workflow runs only when you trigger it (workflow_dispatch — the "Run workflow" button on the Actions tab, or gh workflow run). A full release is two dispatches with a merge in between:

1. Dispatch #1 — the release-please job inspects the conventional commits since the last release and opens/updates a release PR titled like chore(main): release 0.31.0. That PR:
   • bumps .release-please-manifest.json,
   • bumps the fallback version in pkg/version/version.go (via the // x-release-please-version annotation),
   • and contains the pending release notes (in the PR body).
2. Merge the release PR once you're happy with the version + notes.
3. Dispatch #2 — release-please detects the merged release PR, creates the git tag (vX.Y.Z) and the GitHub Release with generated notes, and release_created == true gates the goreleaser job, which builds cross-platform binaries, signs checksums with cosign, generates SBOMs with syft, attaches everything to the release (without overwriting the notes — release.mode: keep-existing), and pushes the updated Homebrew cask to dynatrace-oss/homebrew-tap.

⚠️ Don't forget Dispatch #2: merging the release PR alone does not publish anything, because the workflow only runs on manual dispatch.

There is no CHANGELOG.md file in the repo by design — the GitHub Release is the canonical changelog (skip-changelog: true in release-please-config.json).