buildkite-agent-metrics-release

name	buildkite-agent-metrics-release
description	Prepare a release for buildkite-agent-metrics.

buildkite-agent-metrics Release

When to Use This Skill

Use this skill when you need to cut a new release of buildkite-agent-metrics.

Instructions

1. Make sure the working tree is up to date with main

git fetch origin
git switch main
git pull --ff-only

2. Decide the new version

Find the latest release:

gh release view --repo buildkite/buildkite-agent-metrics --json tagName,publishedAt

Ask the user whether this is a major, minor, or patch bump. Use the bare semver (e.g. 5.13.0), not a v-prefixed tag.

3. Bump the version

Edit version/version.go and set const Version = "X.Y.Z" to the new version.

4. Preview the auto-generated release notes

This is a read-only API call — it does not create a release or tag. GitHub auto-detects the previous release and applies categorisation from .github/release.yml.

notes_file=$(mktemp)
gh api -X POST repos/buildkite/buildkite-agent-metrics/releases/generate-notes \
  -f tag_name=vX.Y.Z \
  -f target_commitish=main \
  --jq .body > "$notes_file"
cat "$notes_file"

Inspect the output. If any PRs are mis-categorised (e.g. landed under 🏠 Internal because they had no category label), fix the labels on those PRs via gh pr edit <num> --add-label feature and re-run the command. The notes are regenerated at release time from current labels.

5. Open the release PR

• Create a branch: git switch -c release/vX.Y.Z.
• Commit the version/version.go change with message release: vX.Y.Z.
• Push and open the PR. The release label is required: it satisfies the PR-labels workflow and excludes this PR from its own auto-generated notes (configured in .github/release.yml).

  gh pr create \
    --title "release: vX.Y.Z" \
    --body-file "$notes_file" \
    --label release
  

The PR body is for human review. The actual release notes are regenerated by gh release create --generate-notes in .buildkite/steps/release-github.sh when the release pipeline runs, so they will reflect any label fixes made between PR creation and release.

6. Merge the PR

Wait for CI to pass, then merge via the GitHub UI or gh pr merge --squash.

7. Done

That's it. The main pipeline build that runs against the merge commit detects the version bump in version/version.go, triggers the release pipeline, and gh release create creates the tag and publishes the release with auto-generated notes.

Spot-check the published release on the Releases page when it appears.