feat(release): trigger from Releases UI (release:published)#14
Merged
Conversation
Switch from `push: tags` to `release: published`. Releases are now
initiated from the GitHub Releases UI ("Draft a new release" → fill
notes → Publish) or via `gh release create vX.Y.Z`. Pushing a tag from
the CLI alone no longer triggers a release.
GoReleaser is configured with:
- `release.mode: append` so user-written notes from the UI are
preserved; GoReleaser's auto-generated changelog and install footer
are appended after the user's text.
- `release.replace_existing_artifacts: true` so re-running the workflow
on the same tag (e.g. after a transient failure) overwrites the
tarballs instead of erroring.
This matches the standard pattern in cli/cli, sigstore/cosign, mise,
and other Go projects that use the Releases UI as the release entry
point.
Co-Authored-By: Claude Opus 4.7
Contributor
There was a problem hiding this comment.
Pull request overview
Updates the release automation to be driven by publishing GitHub Releases (UI/gh), while preserving user-authored release notes and improving workflow re-run behavior for release assets.
Changes:
- Switch GitHub Actions trigger from
pushonv*tags torelease: published. - Configure GoReleaser to append generated content to existing release notes (
release.mode: append). - Allow re-runs to overwrite existing release assets (
release.replace_existing_artifacts: true).
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
.goreleaser.yml |
Appends generated changelog/footer to existing release notes and enables overwriting existing artifacts on reruns. |
.github/workflows/release.yml |
Triggers the release workflow on GitHub Release publish events instead of tag pushes. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Comment on lines
3
to
6
| on: | ||
| push: | ||
| tags: | ||
| - "v*" | ||
| release: | ||
| types: [published] | ||
|
|
Switching from `push: tags: ["v*"]` to `release: published` removed the implicit tag filter — without a guard, any release publish (e.g. a `nightly`, a date tag, or a typo) would run GoReleaser. Add a job-level `if: startsWith(github.event.release.tag_name, 'v')` to restore the original `v*` constraint at the new entry point. Co-Authored-By: Claude Opus 4.7
monotek
approved these changes
May 22, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What did you do?
release.ymlfrompush: tags: ["v*"]torelease: types: [published]. Releases now fire when a release is published via the GitHub Releases UI or viagh release create vX.Y.Z.release.mode: appendto.goreleaser.ymlso user-written notes from the UI are preserved (the auto-generated changelog and install footer are appended after the user's text).release.replace_existing_artifacts: trueso re-running the workflow on the same tag (e.g. after a transient failure) overwrites the tarballs instead of erroring.Why did you do it?
Released v0.0.1 via
git tag && git push origin v0.0.1from the CLI, but the UI flow ("Draft a new release" → write notes → Publish) is more discoverable for future releases — both for us internally and for any external contributors. This change makes it the standard path.Matches the pattern used in cli/cli, sigstore/cosign, jdx/mise, and other Go-CLI projects that drive releases from the Releases UI.
Behavior change
git push origin v0.0.Xtriggers releasegh release create) triggers releaseFor the next release: visit https://github.com/Staffbase/gq/releases/new, pick or create a tag, write notes, click Publish release — workflow takes over from there.
Checklist
I validated locally with
goreleaser check(config valid) andgoreleaser release --snapshot --clean --skip=publish,before(all 4 platform tarballs build).🤖 Generated with Claude Code.