Add GitHub action workflow to automatically build/publish release artifacts after tag is created #835
Conversation
…artifacts after tag is created
…ry-generated-release-notes
…ill prevent goreleaser from creating the release if a tag is pushed before the release is made in the GitHub UI
RELEASE.md
Outdated
| * Target the main branch. | ||
| * Title the Release the same as the tag: “vX.Y.Z”. | ||
| * Click “Set as latest release”. | ||
| * If this is a release candidate, or any other kind of pre-release, click "Set as a pre-release". |
There was a problem hiding this comment.
Can we specifically mention that pre-1.0 releases are not automatically prereleases? Across our OSS, we settled on treating v0.9.5 as a regular release. I assume that also applies to RCs for the 1.0, since we do want to feature those releases on the repository homepage?
There was a problem hiding this comment.
I didn't realize that RCs should not be marked as pre-releases. For Go libraries anyway, using go get -u won't get release candidates, so it seemed okay to align the GitHub release state the same way, by marking them as pre-releases.
I can wordsmith a little on this.
There was a problem hiding this comment.
I added a single statement about pre-v1.0.0 releases. But would like to confirm: do we want release candidates to not be release candidates, too?
There was a problem hiding this comment.
As far as I can tell, the only effect of this checkbox for Go libraries and binaries is controlling whether or not they're featured on the repository homepage. It seems that we want to advertise the existence of v1.0-rc4, right? We might feel differently about RCs for v2, if we ever get there - we'd want most users to continue using 1.x releases instead of blindly updating to something unstable.
|
@akshayjshah, I was just looking at this and realized I totally forgot to describe the process to update the embedded version number via PR. So I just pushed a commit with more words, mostly copied from similar language for connect-go releases. |
I tested this configuration with a personal repo to verify it does what we want. This allows us to hand-curate the release notes in the GitHub UI, but still have
goreleasercreate the artifacts that are part of the release.This also adds a
RELEASE.mddoc to describe the release process, and it's similar to connect-go (which will likely soon have a similar "release" action to publish theprotoc-gen-connect-gobinary as a release artifact) and connect-kotlin (which uses a "release" action to publish to Maven central).