ci: pin goreleaser instead of tracking latest - #35
Merged
Conversation
`version: latest` reached straight past the action's SHA pin and fetched whatever goreleaser had shipped by the time a tag was pushed. The action is pinned to a commit precisely so upstream cannot swap what runs; asking it to install the newest available goreleaser puts that exposure back, on the one job holding the Homebrew tap token. Not hypothetical here. `.goreleaser.yaml` still uses the deprecated `brews:` key — `goreleaser check` warns, and only warns, today. While unpinned, the release that breaks is whichever one happens to run after upstream turns that deprecation into a removal: discovered at release time, with a tag already pushed, which is the worst moment to find out. Pinned to 2.17.1 because that is what CI actually used for v0.2.3 minutes ago, verified end to end — five archives, checksums that validate against the published files, a Homebrew formula pointing at real URLs, and a downloaded binary reporting 0.2.3. That is stronger evidence than "the newest one probably works". Dependabot does not manage this input; it is a value, not an action ref. So it is bumped by hand, like govulncheck in ci.yml, and the comment says what to do when bumping: migrate `brews:` to `homebrew_casks:` first, then run `goreleaser check` and a snapshot build locally before pushing a tag. Worth stating plainly: CI cannot exercise this change, because release.yml only runs on tag pushes. The next tag is the real test. The `brews:` migration is left for its own change rather than folded in here, so that if it does go wrong the pin is not entangled with it.
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.
version: latestreached straight past the action's SHA pin and fetched whatever goreleaser had shipped by the time a tag was pushed.The action is pinned to a commit precisely so upstream can't swap what runs. Asking it to then install the newest available goreleaser puts that exposure right back — on the one job holding
HOMEBREW_TAP_GITHUB_TOKEN, which reaches other people's machines viabrew upgrade.Not hypothetical
.goreleaser.yamlstill uses the deprecatedbrews:key.goreleaser checkwarns about it — and only warns, today:While unpinned, the release that breaks is whichever one happens to run after upstream turns that deprecation into a removal. Discovered at release time, with a tag already pushed — the worst possible moment.
Why 2.17.1 specifically
It's what CI actually used for the v0.2.3 release minutes ago, verified end to end:
checksums.txtnamecom_darwin_arm64.tar.gz: OK)0.2.3, URLs resolvecurlURL"version": "0.2.3"That's stronger evidence than "the newest one probably works."
Maintenance
Dependabot doesn't manage this input — it's a value, not an action ref — so it's bumped by hand, same as
govulncheckinci.yml. The comment records what to do when bumping: migratebrews:→homebrew_casks:first, then rungoreleaser checkand a snapshot build locally before pushing a tag.Honest limitation
CI cannot exercise this change.
release.ymlonly runs on tag pushes, so the next tag is the real test. I've left thebrews:migration for its own change rather than folding it in, so that if that migration goes wrong, it isn't entangled with the pin.Test plan
release.ymlparses as valid YAMLv2.17.1confirmed to exist upstream (published 2026-07-26)goreleaser release --snapshot --cleansucceeds against this config locally (on 2.17.0)