ci: gate the release build in the PR, not at the tag - #248
Merged
Conversation
The v1.6.0 tag build failed on a config that every CI gate had passed: .goreleaser.yaml named `cmd/acor/main.go`, a file, so GoReleaser compiled main.go alone and dropped dictionary.go alongside it. Two holes let that reach a tag. .goreleaser.yaml was not in the path filter, so a PR touching only it ran no CI at all; and CI ran no builder that reads that file, so even with the filter nothing would have compiled it. `make build` builds ./cmd/acor — a different build than the release's, which is precisely why a green main proved nothing about the tag. Adds both halves: the path entry, and a `goreleaser build --snapshot --single-target` step on one matrix leg. build rather than release, so it needs no tokens and publishes nothing; single-target keeps it to the host platform, which is enough to fail a config that cannot compile. Verified by reintroducing the bug locally: the step fails with the tag build's own error, `undefined: dispatchDictionary`.
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.
Pull Request
Description
Follow-up to #247. That PR fixed the broken
.goreleaser.yamlline; this one closes the hole that let it reach a tag unnoticed.The v1.6.0 tag build failed on a config every CI gate had passed. Two separate holes were needed for that:
.goreleaser.yamlwas not in the path filter. A PR touching only that file ran no CI at all — which is exactly what fix: build the acor package, not main.go alone, in the release #247 did, merging on a greenlabelerand nothing else.make buildbuilds./cmd/acor; GoReleaser builds whatever.goreleaser.yamlnames. For v1.6.0 those were different things, which is why a greenmainproved nothing about the tag.Adding only the path entry would have been theater: CI would have run,
make buildwould have passed, and the file-vs-package bug would still merge. Both halves are needed, so both are here.Type of Change
CI-only change — none of the above.
What the new step does
build, notrelease: publishes nothing and needs no tokens, so it is safe on a fork PR.--single-targetkeeps it to the host platform — enough to fail a config that cannot compile, without paying for the nine-target matrix on every PR. Pinned to one matrix leg, matchingtidy-check,license-check, andapi-checkabove it.Verification
Reintroduced the exact bug locally and ran the step's command:
That is the tag build's own error, produced in a PR-time check. Restored the file and reconfirmed the build passes;
git statusshows this PR touchesci.yamlonly.Checklist
make test) — no Go files changed; pre-commit skipped the Go hooks for that reasonmake vet— samemake lint) — samemake build) — samechangie new) — deliberately skipped: CI-only, per the rule stated on this templateAdditional Notes
Unlike #247, this PR will run full CI, since
.github/workflows/*.yamlwas already in the filter — so the new step gets exercised on its own PR.By submitting this PR, I agree that my contributions will be licensed under the Apache License 2.0.