ci: validate the goreleaser config on every PR - #117
Merged
Conversation
The dockers/docker_manifests and brews deprecations both reached us as warnings printed at the top of every release run, where a green job means nobody reads the log. Nothing validated .goreleaser.yaml, so the only feedback loop for release config was a release itself. Run 'goreleaser check' in the existing lint job -- it exits non-zero on deprecated options, which is exactly the signal we were missing. Adding it as a step rather than a new job keeps it inside a check branch protection already requires. Pin GORELEASER_VERSION in ci.yml to match release.yml so the config is validated against the same goreleaser that publishes it, and widen the renovate custom manager to both workflows so the two pins cannot drift.
sergiught
force-pushed
the
ci/validate-goreleaser-config
branch
from
August 3, 2026 09:54
4a014b6 to
7a08268
Compare
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
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
Both deprecations fixed in #115 and #116 reached us the same way: as warnings printed at the top of every release run, where a green job means nobody reads the log. Nothing in CI validated
.goreleaser.yaml, so the only feedback loop for release config was running a release.This runs
goreleaser checkon every PR. It exits non-zero on deprecated options — that is the point, and precisely the signal we were missing.Two supporting details:
lintjob, not a new job. Branch protection pins bare job names, so a new job would not be a required check until it is added there by hand; a step insidelintis enforced immediately.GORELEASER_VERSIONpinned inci.ymlto matchrelease.yml, so the config is validated against the same goreleaser that publishes it. The renovate custom manager previously matched onlyrelease.yml, so a second pin would have silently drifted —managerFilePatternsnow covers both workflows, keeping them in lockstep in a single renovate PR.⛔ Merge last — CI on this PR is red until #115 and #116 land
This PR is the last in the sequence by necessity.
mainstill carries both deprecations, sogoreleaser checkfails against it:That red check is the change working as intended, not a defect. Merge order: #114 → #115 → #116 → this.
Verified locally that the premise holds — with both migrations applied, the check passes:
🏷 Type of change
🔗 Related issues
Completes the sequence started by #114 (attestations surviving a late-publisher failure), #115 (
dockers_v2), #116 (homebrew_casks).✅ How to verify
📋 Checklist
actionlintcleanmake checkpasses locally — n/a, no Go code touched