dtctl-release

dtctl のリリースプロセス（release-please）

dtctl のリリースには release-please を使用しますが、手動でトリガーする必要があります — main への通常のマージでは何もリリースされません。手動でのバージョン更新は不要で、編集する CHANGELOG.md も、手動でプッシュするタグもありません。リリースノートとバージョンは、前回のリリース以降の Conventional Commits に基づいて算出されます。

仕組み

.github/workflows/release.yml ワークフローは、手動でトリガーした場合にのみ実行されます（workflow_dispatch — Actions タブの「Run workflow」ボタン、または gh workflow run）。完全なリリースは、間にマージを挟んで、2 回のディスパッチで行われます。

1. ディスパッチ #1 — release-please ジョブが前回のリリース以降の Conventional Commits を確認し、chore(main): release 0.31.0 のようなタイトルのリリース PRを作成または更新します。この PR では次の処理が行われます。
   • .release-please-manifest.json のバージョンを更新します。
   • pkg/version/version.go のフォールバックバージョンを更新します（// x-release-please-version アノテーションを使用）。
   • リリースノート案が PR の本文に含まれます。
2. リリース PR をマージ — バージョンとリリースノートに問題がないことを確認してからマージします。
3. ディスパッチ #2 — release-please がマージ済みのリリース PR を検出し、git タグ（vX.Y.Z）と、生成されたリリースノートを含むGitHub Releaseを作成します。release_created == true を条件として goreleaser ジョブが実行され、クロスプラットフォームのバイナリをビルドし、cosign でチェックサムに署名し、syft で SBOM を生成し、リリースノートを上書きせず（release.mode: keep-existing）すべてをリリースに添付して、更新された Homebrew cask を dynatrace-oss/homebrew-tap にプッシュします。

⚠️ ディスパッチ #2を忘れないでください。リリース PR をマージしただけでは、ワークフローは手動ディスパッチ時にしか実行されないため、何も公開されません。

設計上、リポジトリには**CHANGELOG.md ファイルがありません** — GitHub Release が正式な変更履歴です（release-please-config.json の skip-changelog: true）。

バージョンの更新幅はコミット種別で決まります

コミットのプレフィックス	更新幅（1.0 未満）	例
feat:	マイナー	0.30.3 → 0.31.0
fix: / perf:	パッチ	0.30.3 → 0.30.4
feat!: / fix!: または BREAKING CHANGE: フッター	マイナー（1.0 未満）	0.30.3 → 0.31.0
docs: / test: / chore: / ci: / refactor:	単独ではリリースされません	—

つまり、「バージョンを制御する」には、適切な Conventional Commits を記述することが重要です（CONTRIBUTING.md を参照）。PR は squash マージされるため、PR のタイトルがリリース対象のコミットになります。

リリースを作成するには

# 1. Dispatch the workflow to build/update the release PR from commits since the last release
gh workflow run release.yml
gh run watch    # wait for the release-please run to finish

# 2. Review the proposed version + notes, then merge the release PR
gh pr list --search "chore(main): release in:title" --state open
gh pr merge <number> --squash

# 3. Dispatch AGAIN to create the tag + GitHub Release and publish artifacts
gh workflow run release.yml
gh run watch

# 4. Confirm
gh release view "$(gh release list --limit 1 --json tagName -q '.[0].tagName')"

タグ、GitHub Release、バイナリ、署名、SBOM、Homebrew cask は、2 回目のディスパッチで作成されます。

リリースノートの調整（任意）

release-please は、PR へのリンクを含む、コミット種別ごとにグループ化されたリリースノートを生成します。デフォルトの内容で問題ありません。より詳しい文章にしたい場合は、公開後に GitHub Release を編集してください。GoReleaser は keep-existing を使用するため、編集内容が上書きされることはありません。

gh release edit vX.Y.Z --notes-file notes.md

トラブルシューティング

• リリース PR が作成されない — ワークフローをディスパッチしましたか？マージ時には実行されません。gh workflow run release.yml を実行してください。実行したのに PR が作成されない場合は、前回のリリース以降にリリース対象のコミットがない（docs／chore／test などのみ）、または有効な Conventional Commit ではないコミットがあります。gh run list --workflow=release.yml で確認してください。
• リリース PR をマージしたのに何も公開されない — これは想定どおりです。ワークフローをもう一度ディスパッチして、release-please がタグ／Release を作成し、GoReleaser が実行されるようにしてください。
• バージョンの更新幅が違う — コミット種別が原因です。特定の更新幅を強制するには、main 上のコミットに Release-As: x.y.z フッターを追加してください。
• リリースは作成されたがバイナリがない — リリースワークフローの実行で goreleaser ジョブを確認してください。このジョブを実行するには、release-please ジョブの出力が release_created: true である必要があります。
• Homebrew が更新されない — HOMEBREW_TAP_APP_ID／HOMEBREW_TAP_APP_PRIVATE_KEY シークレットと、GoReleaser のステップログを確認してください。skip_upload: auto は、プレリリースタグを意図的にスキップします。

チェックリスト

1. 意図した変更がすべて、Conventional Commit として main にマージされている
2. ディスパッチ #1：gh workflow run release.yml → リリース PR が作成または更新される
3. オープン中のリリース PR に、想定されたバージョンとリリースノートが反映されている
4. リリース PR をマージする（スカッシュ）
5. ディスパッチ #2：gh workflow run release.yml → タグとリリースが作成される
6. release.yml の実行で、release-please と goreleaser の両方のジョブが成功している
7. GitHub Release にバイナリ、チェックサム、署名、SBOM が表示されている
8. （任意）gh release edit でリリースノートを整える