ci: release through version.json and the org's shared workflows - #2
Merged
Conversation
Adopts the release tooling the other Go repositories here use: bump version.json, label the pull request `release`, merge, and the tag and GitHub Release follow. Replaces the tag I pushed by hand for v0.1.0, which nothing recorded and nobody could review. version.json is seeded at v0.1.0 to match the existing tag, so installing this does not itself release anything — release-publish sees the tag and no-ops. The next bump is the first one the tooling performs. The part worth knowing is that release-check earns its place on a LIBRARY, which is not what I assumed when I started wiring this. It runs `gorelease` and `gocompat` against the previous tag: the Go project's own API-compatibility checkers, comparing the exported surface to the last release and reporting whether the version increment is semver-honest. For a module whose whole purpose is to be imported, catching a breaking change under a patch bump is worth more than any build artifact. It also only proposes a tag when the pull request carries a `release` label, so an ordinary version edit on a feature branch cannot release by accident. Deliberately NO goreleaser-release job, unlike sei-chain's integration. This module is a library, so the tag IS the release — `go get` resolves a version from the module proxy, which reads it from the tag, and there is no binary to build or attach. The repositories that chain goreleaser after release-publish are shipping a command. The comment in uci-release-publish.yml says where that job would go if this ever does. Both callers pin uci@v0.0.15, the current tag, rather than the mixed v0.0.9 and v0.0.11 an older integration ended up on. release-check is triggered by pull_request_target because it needs a token that can comment on the pull request, which a fork-originated run does not get. That makes the trigger privileged, so it is worth stating why it is safe: nothing in these files checks out or executes pull-request code, and the reusable workflow reads version.json through the API at the head SHA rather than from a checkout.
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 join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Adopts the release tooling the other Go repositories here use — bump
version.json, label the PRrelease, merge, and the tag and Release follow. Replaces thev0.1.0tag I pushed by hand, which nothing recorded and nobody could review.version.jsonis seeded atv0.1.0to match the existing tag, so merging this releases nothing —release-publishsees the tag and no-ops. The next bump is the first one the tooling performs.What changed my mind while wiring this
I expected
release-checkto be binary-oriented and only marginally useful for a library. It isn't. It runsgoreleaseandgocompatagainst the previous tag — the Go project's own API-compatibility checkers. They compare the exported surface to the last release and report whether the version increment is semver-honest.For a module whose entire purpose is to be imported, catching a breaking change under a patch bump is worth considerably more than any build artifact. That check is the main reason to adopt this rather than keep tagging by hand.
It also only proposes a tag when the PR carries a
releaselabel, so an ordinary version edit on a feature branch can't release by accident.One deliberate omission
No
goreleaser-releasejob, unlike sei-chain's integration.This module is a library, so the tag is the release —
go getresolves a version from the module proxy, which reads it from the tag. There is no binary to build and nothing to attach. The repos that chain GoReleaser afterrelease-publishare shipping a command; we aren't. The comment inuci-release-publish.ymlrecords where that job would go if this ever does.If you'd rather have source archives, checksums or an SBOM attached anyway, that's a reasonable thing to want and I can add the job — it just isn't on the path a Go consumer uses.
Notes
uci@v0.0.15, the current tag, rather than the mixedv0.0.9/v0.0.11an older integration drifted onto.release-checkusespull_request_targetbecause it needs a token that can comment on the PR, which a fork-originatedpull_requestrun doesn't get. That trigger is privileged, so worth stating why it's safe here: nothing in these files checks out or executes PR code, and the reusable workflow readsversion.jsonthrough the API at the head SHA rather than from a checkout.bin/check.shstill passes; no Go source changed.