dynatrace-oss/dtctl

dtctl-release

Explain and operate the dtctl release process, which is automated by release-please.

소스 보기

사용 방법

  1. 설치 명령을 복사하고 자신의 에이전트 환경에 설치하기 전에 소스 패키지를 확인하세요.
  2. 필요한 도구, 인증 정보, 지원 환경은 원본 문서에서 확인하세요.
  3. 입력과 원하는 산출물을 설명하고 출처와 결과를 대조하세요.
npx skills add https://github.com/dynatrace-oss/dtctl --skill dtctl-release

시작 전 확인

  • 설치에는 모델 구독, API 한도, 파일 접근 권한이 포함되지 않습니다.
  • 별점 수와 설치 수는 활동 지표이며 독립적인 품질·보안 검증이 아닙니다.
원본 Skill 문서

원본 저장소의 제목, 예시, 코드, 표, 링크, 이미지를 유지해 표시합니다.

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).
  1. Merge the release PR once you're happy with the version + notes.
  2. 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).

Version bumps are determined by commit type

Commit prefixBump (pre-1.0)Example
feat:MINOR0.30.3 → 0.31.0
fix: / perf:PATCH0.30.3 → 0.30.4
feat!: / fix!: or BREAKING CHANGE: footerMINOR (pre-1.0)0.30.3 → 0.31.0
docs: / test: / chore: / ci: / refactor:no release on its own—

So the way to "control the version" is to write good conventional commits (see CONTRIBUTING.md). PRs are squash-merged, so the PR title becomes the release-relevant commit.

To cut a release

bash
# 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')"

The tag, GitHub Release, binaries, signatures, SBOMs, and Homebrew cask are produced by the second dispatch.

Polishing release notes (optional)

release-please generates notes grouped by commit type with PR links. They're good by default. If you want richer prose, edit the GitHub Release after it's published — GoReleaser uses keep-existing, so it won't clobber your edits:

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

Troubleshooting

  • No release PR appeared — did you dispatch the workflow? It does not run on merges; run gh workflow run release.yml. If it ran and still no PR, there are no releasable commits since the last release (only docs/chore/test/etc.), or a commit isn't a valid conventional commit. Check gh run list --workflow=release.yml.
  • Merged the release PR but nothing published — that's expected: dispatch the workflow a second time so release-please creates the tag/Release and GoReleaser runs.
  • Wrong version bump — caused by the commit types. To force a specific bump, use a Release-As: x.y.z footer in a commit on main.
  • Release created but no binaries — inspect the goreleaser job in the release workflow run; the release-please job must have output release_created: true for it to run.
  • Homebrew didn't update — check the HOMEBREW_TAP_APP_ID / HOMEBREW_TAP_APP_PRIVATE_KEY secrets and the GoReleaser step logs; skip_upload: auto intentionally skips pre-release tags.

Checklist

  1. [ ] All intended changes merged to main as conventional commits
  2. [ ] Dispatch #1: gh workflow run release.yml → release PR created/updated
  3. [ ] Open release PR reflects the expected version and notes
  4. [ ] Merge the release PR (squash)
  5. [ ] Dispatch #2: gh workflow run release.yml → tag + Release created
  6. [ ] release.yml run is green for both release-please and goreleaser jobs
  7. [ ] GitHub Release shows binaries, checksums, signatures, and SBOMs
  8. [ ] (Optional) Polished the release notes via gh release edit

관련 작업

같은 저장소의 Skills

더 많은 Skills

모든 Skills