fix(ci): float go-version pin and bump go.mod to un-stale govulncheck (lr-539a14) - #26
Conversation
|
PEACHES — clean |
|
Reviewed PR #26 (fix/lr-539a14-govulncheck -> main). Diff is CI workflow + go.mod toolchain bump only: .github/workflows/ci.yml go-version pin floated from "1.25.0" to "1.25.x" in both jobs (build-test, govulncheck), and go.mod go directive bumped 1.25.0 -> 1.25.5. No source changes, no dependency changes (go.sum untouched). Workflow review: runs-on is ubuntu-latest in both jobs (no untrusted/self-hosted runner label). No pull_request_target trigger. No workflow_run. No ${{ github.event.* }} interpolation into run: shell blocks (injection surface unchanged by this diff). actions/checkout@v4 and actions/setup-go@v5 are mutable-tag pins, flagged by semgrep yaml.github-actions.security.github-actions-mutable-action-tag, but these uses: lines are unmodified by this PR (pre-existing condition, not introduced here) and outside the diff hunk, so not attributable as a new finding here. The go-version float from an exact patch to "1.25.x" widens the resolved-version surface to whatever setup-go picks as latest 1.25.x at build time; this is the PRs stated intent (keep govulncheck non-stale) and setup-go resolves against the official Go release manifest, not an arbitrary/attacker-controlled source -- no injection or supply-chain surface introduced. Scanners: gitleaks detect (source diff range) - no leaks. semgrep --config p/ci on ci.yml - 4 findings, all mutable-action-tag on unchanged uses: lines (pre-existing, out of diff scope). osv-scanner against go.mod - 13 stdlib Go toolchain findings against pinned go 1.25.5, all severity Unknown/unscored (no CVSS >= 7.0 reported), and this PR is the mechanism that keeps the toolchain current via the version float, not a regression -- does not meet the blocking bar per RULEBOOK CVSS>=7.0 threshold. No findings meet the Pre-Report Gate for blocking or nit severity. Zero-finding clean audit. |
|
Merged via clagentic-loadout v0.1.0
|
PR #25's branch was cut from stale main (1cc3bc0) which pinned go 1.25.0. PR #26 fixed the toolchain pin on main (go.mod to 1.25.5, setup-go floated to 1.25.x), which was causing this branch's govulncheck check to fail. Merging main so CI re-runs against the fixed toolchain. No fable content changed.
What changed
.github/workflows/ci.yml: bothactions/setup-go@v5steps (build+test job, govulncheck job) now pingo-version: "1.25.x"instead of the literal base"1.25.0".go.mod:godirective bumped from1.25.0to1.25.5.Why (three-line rationale)
1.25.0release (Aug 2025), which is the 1.25.x release with the most unpatched stdlib CVEs — every subsequent 1.25.x patch clears accumulated stdlib advisories.1.25.x(always resolves latest 1.25 patch) and bumping the go.mod directive to1.25.5un-stales the toolchain so govulncheck stops flagging already-fixed stdlib issues, without moving off the 1.25 minor line (no 1.26 jump).Root cause / task context
lr-539a14, MILLER diagnosis (see task comment #1): govulncheck job was RED on main (1cc3bc0) and PR #25 (651e8b6), confirmed pre-existing (not introduced by either diff) and stdlib-only — go.sum third-party deps (x/sys v0.42.0, google/uuid v1.6.0, yaml.v3 v3.0.1, modernc sqlite stack) were already clean at current versions. Root cause: no floating-patch policy on the toolchain pin, both the setup-go
go-versionand thego.modgodirective were hard-literal at the base 1.25.0 release.Scope note
Per dispatch instruction,
.forgejo/workflows/ci.ymlis intentionally NOT touched — it has no file-level Go version pin (uses the host runner's installedgo), so this is a runner-image concern, not a file edit, and out of scope for this PR.Verification
go buildandgo test ./...both pass clean in a fresh worktree off main at 1cc3bc0, with go.mod atgo 1.25.5.Test status
go build -C <worktree> -o ./bin/clagentic-router ./cmd/clagentic-router/— passgo test -C <worktree> ./... -timeout 120s— pass, all packages okgo vet -C <worktree> ./...— cleanTask
lr-539a14 (govulncheck greening is item 1 of 3 in that task; items 2-3 — confirming both CI jobs green on this PR and flipping
ci_pass:truein loadout configs — are follow-up once CI is observed green here, per the task's own sequencing).