mcpField
D
dtctl-release

dtctl-release

github.com/dynatrace云与 DevOps198585 次安装1 周前更新
代码仓库

关于 dtctl-release

面向 dtctl 维护者的发布流程技能，说明如何手动分两次触发 release-please，以及 Conventional Commits 如何决定版本和发布说明。

主要功能

  1. 01两次手动触发的发布流程
  2. 02Conventional Commits 版本规则
  3. 03发布 PR 审核与合并步骤
  4. 04二进制文件、校验和、签名及 SBOM 发布
  5. 05故障排查与发布清单

适用场景

  1. 01准备并发布 dtctl 版本
  2. 02排查发布 PR 未创建或发布未完成
  3. 03确认哪些提交类型会触发版本变更

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/dynatrace/dtctl --skill dtctl-release

安装后在 Claude Code 中输入/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）。完整发布分为两次触发，中间需要合并一次：

  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（不会覆盖说明——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:MINOR0.30.3 → 0.31.0
fix: / perf:PATCH0.30.3 → 0.30.4
feat!: / fix!: 或 BREAKING CHANGE: 页脚MINOR（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 均由第二次触发生成。

润色发布说明（可选）

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 Commits 规范。检查 gh run list --workflow=release.yml。
  • 合并发布 PR 后没有发布任何内容——这是预期行为：请第二次触发工作流，让 release-please 创建标签和 Release，并运行 GoReleaser。
  • 版本提升不正确——这是由提交类型导致的。要指定特定的版本提升，请在 main 上的提交中使用 Release-As: x.y.z 页脚。
  • 已创建 Release，但没有二进制文件——检查发布工作流运行中的 goreleaser 作业；release-please 作业必须输出 release_created: true，该作业才会运行。
  • Homebrew 未更新——检查 HOMEBREW_TAP_APP_ID / HOMEBREW_TAP_APP_PRIVATE_KEY 密钥和 GoReleaser 步骤日志；skip_upload: auto 会有意跳过预发布标签。

检查清单

  1. 所有预期变更均已作为符合规范的提交合并到 main
  2. 触发第 1 次：gh workflow run release.yml → 已创建或更新发布 PR
  3. 打开的发布 PR 反映了预期版本和说明
  4. 合并发布 PR（压缩合并）
  5. 触发第 2 次：gh workflow run release.yml → 已创建标签和 Release
  6. release.yml 运行成功，release-please 和 goreleaser 作业均通过
  7. GitHub Release 显示了二进制文件、校验和、签名和 SBOM
  8. [ ]（可选）通过 gh release edit 润色发布说明

评论

支持 Markdown