fix(ci): install the release Go toolchain from go.mod#66
Merged
Conversation
The GoReleaser release job hardcoded go-version: "1.25.1", but #63 bumped the go.mod floor to go 1.25.10 (required for deadcode@v0.43.0). setup-go pins GOTOOLCHAIN=local for an explicit go-version, so GoReleaser failed immediately at "getting and validating git state": failed to get module path: go: go.mod requires go >= 1.25.10 (running go 1.25.1; GOTOOLCHAIN=local) The v1.0.2 and v1.0.3 tag releases never published as a result. Read the Go version from go.mod (as CI already does via the reusable validate-go-project workflow) so the release toolchain tracks the floor and can't drift below it again. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
Pull request overview
Fixes the broken CD - Go release pipeline by sourcing the Go toolchain version from go.mod instead of a hardcoded 1.25.1, which was below the go 1.25.10 floor and caused GoReleaser to fail under GOTOOLCHAIN=local.
Changes:
- Replace
go-version: "1.25.1"withgo-version-file: go.modin the GoReleaser setup-go step. - Add an explanatory comment about why the floor must be tracked dynamically.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
✅
|
| Descriptor | Linter | Files | Fixed | Errors | Warnings | Elapsed time |
|---|---|---|---|---|---|---|
| ✅ ACTION | actionlint | 6 | 0 | 0 | 0.4s | |
| ✅ ACTION | zizmor | 6 | 0 | 0 | 0 | 2.36s |
| ✅ COPYPASTE | jscpd | yes | no | no | 1.07s | |
| ✅ GO | golangci-lint | yes | yes | no | no | 13.2s |
| ✅ JSON | jsonlint | 1 | 0 | 0 | 0.31s | |
| ✅ JSON | prettier | 1 | 0 | 0 | 0 | 0.5s |
| ✅ JSON | v8r | 1 | 0 | 0 | 2.91s | |
| markdownlint | 4 | 0 | 4 | 0 | 0.94s | |
| ✅ MARKDOWN | markdown-table-formatter | 4 | 0 | 0 | 0 | 0.19s |
| ✅ REPOSITORY | checkov | yes | no | no | 22.26s | |
| ✅ REPOSITORY | gitleaks | yes | no | no | 0.08s | |
| ✅ REPOSITORY | git_diff | yes | no | no | 0.0s | |
| ✅ REPOSITORY | grype | yes | no | no | 49.57s | |
| ✅ REPOSITORY | osv-scanner | yes | no | no | 0.43s | |
| ✅ REPOSITORY | secretlint | yes | no | no | 0.96s | |
| ✅ REPOSITORY | syft | yes | no | no | 1.6s | |
| ✅ REPOSITORY | trivy | yes | no | no | 11.9s | |
| ✅ REPOSITORY | trivy-sbom | yes | no | no | 0.21s | |
| ✅ REPOSITORY | trufflehog | yes | no | no | 3.51s | |
| ✅ SPELL | lychee | 15 | 0 | 0 | 1.2s | |
| ✅ YAML | prettier | 10 | 0 | 0 | 0 | 0.38s |
| ✅ YAML | v8r | 10 | 0 | 0 | 11.37s | |
| ✅ YAML | yamllint | 10 | 0 | 0 | 0.62s |
Detailed Issues
⚠️ MARKDOWN / markdownlint - 4 errors
.claude/skills/maintain/SKILL.md:5 error MD041/first-line-heading/first-line-h1 First line in a file should be a top-level heading [Context: "Perform maintenance per the **..."]
AGENTS.md:5:401 error MD013/line-length Line length [Expected: 400; Actual: 436]
AGENTS.md:31:401 error MD013/line-length Line length [Expected: 400; Actual: 1143]
CLAUDE.md:1 error MD041/first-line-heading/first-line-h1 First line in a file should be a top-level heading [Context: "@AGENTS.md"]
Notices
📣 MegaLinter 9.5.0 is out! Discover the new features and security recommendations in the release announcement. (Skip this info by defining SECURITY_SUGGESTIONS: false)
See detailed reports in MegaLinter artifacts

Show us your support by starring ⭐ the repository
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.
Problem
The
CD - Gorelease pipeline has been failing since the go.mod floor was bumped. The GoReleaser job in.github/workflows/cd.yamlhardcodedgo-version: "1.25.1", but #63 raised thego.modfloor togo 1.25.10(needed fordeadcode@v0.43.0).actions/setup-gopinsGOTOOLCHAIN=localwhen given an explicitgo-version, so GoReleaser bailed immediately at "getting and validating git state":As a result the
v1.0.2andv1.0.3tag releases never published (run 26451728699, run 26451227121).mainCI stayed green throughout because CI installs Go via the reusablevalidate-go-projectworkflow'sgo-version-file: go.mod— only this local CD workflow drifted.Fix
Read the release Go version from
go.mod(go-version-file: go.mod) instead of a hardcoded string, mirroring what CI already does. The release toolchain now tracks the floor automatically and can't silently drift below it again on the next bump.Validation
actionlint .github/workflows/cd.yaml— clean.cache: false(cache-poisoning guard) is unchanged; no new dependency; no caller-interface change.Notes
Holistic follow-up (not in this PR): other Go products with a GoReleaser CD that hardcode
go-versionwould hit the same wall once theirgo.modfloor moves past the pin — worth a consistency sweep (e.g. ksail). Tracked in the run report.