@@ -55,9 +55,10 @@ timeout`), which is what drives release-please's version bumps. Individual
5555 a comment: that belongs in the PR description and rots as the code moves
5656 on.
5757- ** Go 1.26.** Check ` go.mod ` 's ` go ` directive and ` .mise/config.toml ` 's
58- ` tools.go ` for the exact pinned versions before assuming they match:
59- Renovate bumps them independently, so a patch-version gap between the two
60- is normal, not a bug to "fix" reflexively. When a newer construct is
58+ ` tools.go ` for the exact pinned versions. Renovate bumps them together
59+ in one grouped Go-toolchain PR, patch releases included, so the two
60+ should match; a lingering gap means a toolchain PR hasn't merged yet
61+ (or something is off) and is worth flagging, not routine drift. When a newer construct is
6162 genuinely more idiomatic, use it: Go 1.26 added ` errors.AsType[T](err) ` , a
6263 generic type-safe replacement for the ` var t *T; errors.As(err, &t) `
6364 two-step; prefer it in new code. ` go fix ` (rebuilt in 1.26 as a
@@ -190,7 +191,8 @@ assuming.
190191
191192## Security
192193
193- ` govulncheck ./... ` (` go install golang.org/x/vuln/cmd/govulncheck@latest ` )
194- isn't wired into CI anywhere in the fleet yet. Run it before cutting a
195- release regardless, and consider proposing it as a ` mise run ` task / CI job
196- here.
194+ ` govulncheck ./... ` runs in CI as the ` Go Vulncheck ` job, via `mise run
195+ vulncheck` with the tool version pinned in ` .mise/config.toml`. Run the
196+ same task locally before cutting a release; a new advisory that fails the
197+ job is an action item (upgrade the module or the Go toolchain), not noise
198+ to suppress.
0 commit comments