Repository navigation
Verify the release pipeline and document distribution (GH-47) - #95
Merged
Merged
Conversation
The pinned goreleaser image shipped Go 1.26.1 with GOTOOLCHAIN=local, so every dry-run died on `go.mod requires go >= 1.26.5` before it built a single binary. Bump the image and let go.mod pin the toolchain, the way the release workflow already does via go-version-file.
The platform matrix, the static linking, the tap coordinates, the secret name, and the quarantine hook are all things a release ships or fails to ship without anything going red. The pipeline was verified by hand once; this is what keeps it verified.
A new architecture page for distribution: what a release produces, the three install channels and which of them report a real version, why the cask needs its own token and its own quarantine hook, and how to verify all of it without publishing anything.
The release pipeline is verified and v0.1.0-rc.1 is next, so the notice stops being true. A shipped tool whose README says it is not ready to use is worse than no notice at all.
Ilyes512
force-pushed
the
chore/GH-47-verify-release
branch
from
August 11, 2026 14:13
268017d to
3757d1f
Compare
7 tasks done
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.
Summary
task release:dry-runwas broken. The pinned goreleaser image shipped Go 1.26.1 withGOTOOLCHAIN=local, so every dry-run died ongo.mod requires go >= 1.26.5before buildinganything. Image bumped to v2.17.1 and
GOTOOLCHAIN=auto, sogo.modis the only toolchain pin —the same thing the release workflow does via
go-version-file.linux/darwin×amd64/arm64),four archives each carrying
labelsync/LICENSE/README.md,checksums.txt, and a rendered cask.A tagged non-snapshot build in a scratch clone (
--skip=publish,validate,announce) taggedv0.1.0-rc.1produced a binary reportinglabelsync version 0.1.0-rc.1and a cask pinned to thesame string — so the
-X .../internal/cmd.Versioninjection reacheslabelsync version.goreleaser checkvalidates the config.HOMEBREW_TAP_GITHUB_TOKENis present as an organisation secret visible to this repository,and
specsnl/homebrew-tapis writable (admin) with aCasks/directory that already holdsspecs.rb..goreleaser.yml: the platform matrix,CGO_ENABLED=0, the tap coordinates,that the secret the cask reads is the one the workflow passes, and the
xattr -dr com.apple.quarantinehook. Each of those can go missing without anything going red today.docs/content/docs/architecture/distribution.md: the pipeline, thethree install channels and which report a real version, the cask and its token, and how to verify
it all without publishing.
Left for after this merges
Tagging
v0.1.0-rc.1for real, then verifyingbrew install specsnl/tap/labelsyncandgo install ...@latestagainst the published release — those need the release to exist, and therelease should contain this branch. Those three boxes in the issue stay unticked until then.
Closes #47