ci: track the go toolchain from go.mod - #467
Merged
Merged
Conversation
CI pinned go-version: "1.25.x" in every setup-go step, and setup-go sets GOTOOLCHAIN=local, so nothing could upgrade on its own. Two failures followed once dependencies moved to Go 1.26: - govulncheck's install pulls x/vuln v1.8.0, which needs go >= 1.26. The install failed, the scan ran a missing binary, and the job failed two steps later on an empty SARIF file. - The mvdan.cc/sh v3.14.1 bump raises the go directive to 1.26.0, which CI could not build at all. Reading the version from go.mod keeps the toolchain and the directive from drifting apart again. set -euo pipefail on the security scan makes an install failure fail that step with its real error instead of uploading an empty SARIF. The CI branch still exits 0 when vulnerabilities are found, so reporting is unchanged; the local branch now exits non-zero, which validate does not run. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
The pinned v2.5.0 release binary is built upstream with go1.25, and golangci-lint refuses to run when its own build's language version trails the targeted one - so raising the go directive to 1.26.0 broke the lint job: can't load config: the Go language version (go1.25) used to build golangci-lint is lower than the targeted Go version (1.26.0) go run builds it with this repo's toolchain, so the two cannot diverge again, and it pins one version for CI and local runs instead of deferring to whatever is on PATH. That gap is why this stayed hidden: local runs used 2.7.2 built with go1.26 while CI ran a 2.5.0 binary built with go1.25. The version stays at v2.5.0, which reports no issues. Later releases are clean to adopt but surface 57 new findings, which belong in their own change. install tools no longer installs golangci-lint, leaving one pin rather than two to keep in step. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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.
What's failing
Every open PR — and
mainitself — fails thesecurityjob. PR #461 (mvdan.cc/sh3.13.1 → 3.14.1) fails every job. Both come from the same place: CI pinsgo-version: "1.25.x"in all 14setup-gosteps, andsetup-gosetsGOTOOLCHAIN=local, so nothing can upgrade on its own.security(all PRs +main):The reported error (
Invalid SARIF. JSON syntax error: Unexpected end of JSON input, at the upload step) is a downstream symptom. The scan script had noset -e, so a failed install and a missing binary both continued, wrote an emptygovuln.sarif, and printed "Security scan completed". This started when x/vuln v1.8.0 was published; it is not caused by any of the PRs.#461: the new
mvdan.cc/shneeds Go 1.26, so dependabot raised thegodirective to1.26.0— which CI cannot build.The change
setup-gosteps usego-version-file: go.modinstead of a hardcoded1.25.x, acrossci.yaml,codeql.yaml,release.yamlandwindows-ci.yml. The toolchain now follows the directive rather than drifting from it.go.mod:go 1.25.8→1.26.0, which is whatx/vulnandmvdan.cc/shrequire. The Dockerfile is already ongolang:1.27.0-bookworm.set -euo pipefailon the security scan, so an install failure fails that step with its real error instead of uploading an empty SARIF.$CIis now read as${CI:-}soset -udoesn't trip on it when unset locally.