Fix goreleaser version mislabeling when multiple tags share a commit - #26
Conversation
All four .goreleaser configs sort tags with -version:refname, so when multiple environment tags point at the same commit (e.g. qc/beta/qc-stable cut from the same develop HEAD), goreleaser's git-based tag detection picks whichever tag sorts highest rather than the one that actually triggered the run — silently baking the wrong version into main.version. Set GORELEASER_CURRENT_TAG to $GITHUB_REF_NAME so goreleaser always uses the triggering tag instead of inferring it from git state. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
There was a problem hiding this comment.
Copilot review overview
🟢 Approval recommended
The change is a small, correct, well-scoped CI fix whose bash array usage, tag-ref gating, and goreleaser override variable were all verified, with no other build step needing the same fix.
Review effort: Balanced
Findings: None
What changed in this PR
This PR fixes a version-mislabeling bug in the release workflow's goreleaser build step. Because all four .goreleaser/config*.yaml files use git.tag_sort: -version:refname, when multiple environment tags (e.g. v0.0.1-beta, v0.0.1-qc, v0.0.1-qc-stable) point at the same commit, goreleaser's git-based "current tag" detection can pick a sibling tag rather than the one that triggered the run, embedding the wrong main.version. The fix pins GORELEASER_CURRENT_TAG to $GITHUB_REF_NAME on tag-triggered runs so the version is deterministic.
Changes:
- On tag-triggered runs, export
GORELEASER_CURRENT_TAG="$GITHUB_REF_NAME"and pass it into the goreleaser container. - Refactor the docker
-eflags into aDOCKER_ENV_ARGSbash array so the new env var is conditionally appended. - Add an explanatory comment documenting the root cause.
| File | Description |
|---|---|
.github/workflows/release.yml |
Pins goreleaser's current tag to the triggering ref on tag runs via a conditional GORELEASER_CURRENT_TAG env var, passed through a new DOCKER_ENV_ARGS array. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Summary
apimetrics-betabuilt from thev0.0.1-betatag reportedapimetrics-beta version 0.0.1-qc-stableinstead of0.0.1-beta, even though the environment (beta-client.apimetrics.io) and config directory were correct..goreleaser/config*.yamlfiles setgit.tag_sort: -version:refname. When several environment tags point at the same commit (as happened here —v0.0.1-beta,v0.0.1-qc, andv0.0.1-qc-stablewere all cut from the samedevelopHEAD), goreleaser's own git-based "current tag" detection picks whichever co-located tag sorts highest under that key (qc-stable>qc>beta), not the tag that actually triggered the run. That value feeds{{.Version}}intomain.versionvialdflags.GORELEASER_CURRENT_TAGto$GITHUB_REF_NAME(the tag that triggered the workflow) before invoking goreleaser, so it no longer infers the version from ambiguous git state. This only applies on tag-triggered runs; branch/snapshot dispatches are unaffected.Detail
This surfaced when three environment builds (
beta,qc,qc-stable) were tagged and pushed against the samedevelopcommit within about a minute of each other.qcandqc-stablehappened to resolve correctly depending on which sibling tags existed on origin at each job's checkout time;betadid not. Pinning the tag removes the race entirely rather than relying on push ordering/timing.Test plan
beta/qc/qc-stablebuild sharing a commit and confirm each binary's--versionoutput matches its own tag, not a sibling's.yq) and reviewed the diff for shell/quoting correctness (noshellcheckavailable locally).