Skip to content

feat(release): automate version + tag via release-please#8

Merged
gok03 merged 1 commit into
mainfrom
chore/release-please
May 19, 2026
Merged

feat(release): automate version + tag via release-please#8
gok03 merged 1 commit into
mainfrom
chore/release-please

Conversation

@gok03
Copy link
Copy Markdown
Contributor

@gok03 gok03 commented May 18, 2026

Summary

Wires up release-please so conventional-commit history on `main` drives a "Release vX.Y.Z" PR. Merging that PR creates the tag + GitHub release, which triggers the existing `release.yaml` → goreleaser → cask publish to `RefuseHQ/homebrew-tap`.

End-to-end flow after this merges:

  1. Any `feat:` / `fix:` / etc. PR merges to `main`.
  2. release-please automatically opens (or updates) a "chore(main): release X.Y.Z" PR with the bumped version + a generated CHANGELOG entry.
  3. You review and merge that PR.
  4. Tag + GitHub release get created.
  5. release.yaml fires, goreleaser builds + signs binaries, publishes the cask file to `RefuseHQ/homebrew-tap`.

No more manual `git tag`.

Files

  • `.github/workflows/release-please.yaml` — release-please action, triggered on push to main.
  • `release-please-config.json` — package type (`go`), versioning rules, pre-1.0 bump policy.
  • `.release-please-manifest.json` — bootstraps at `0.0.0`.
  • `CHANGELOG.md` — truncated to header; release-please rebuilds from commit history. The previous placeholder `[0.0.1]` section referenced a tag that never existed.

Required follow-up

For tag pushes by release-please to trigger the existing release.yaml workflow, set a `RELEASE_PLEASE_TOKEN` secret with a PAT that has `contents: write` on this repo. (GitHub policy: workflows triggered by `GITHUB_TOKEN` don't cascade into other workflows.) The workflow falls back to `GITHUB_TOKEN` if the secret is absent, in which case the release PR opens but the downstream binary publish needs to be re-kicked manually.

Test plan

  • CI green on the PR
  • After merge, release-please opens its first "chore(main): release" PR within ~30s
  • Verify the proposed version + changelog entries in that PR
  • Merge the release PR → tag created → release.yaml runs → binaries land in the GitHub release → cask file pushed to `RefuseHQ/homebrew-tap`

Wires up googleapis/release-please-action@v4 so that conventional-commit
history on `main` drives a "Release vX.Y.Z" PR. Merging that PR creates
the tag + GitHub release, which triggers the existing release.yaml →
goreleaser → cask publish to RefuseHQ/homebrew-tap.

Bootstrapped at 0.0.0; release-please will propose the first real version
on the next push to main (likely 0.1.0 given the feat: commits in
history). CHANGELOG.md reset to a clean header — release-please manages
future entries from commit messages.

Note: for the chain to fire end-to-end without manual intervention, the
release-please workflow needs a PAT (RELEASE_PLEASE_TOKEN) with
`contents: write` on this repo. With only GITHUB_TOKEN, the tag is
created but downstream release.yaml does not fire (GitHub policy on
token-cascaded workflows). The workflow uses the PAT if present and
falls back to GITHUB_TOKEN otherwise.
@gok03 gok03 merged commit f8586b4 into main May 19, 2026
8 checks passed
@gok03 gok03 mentioned this pull request May 19, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant