chore(deps): batch all pending dependency updates and fix CI

[rdimitrov]

Folds all 21 open Dependabot/Renovate PRs into a single change, fixes the two unrelated CI failures that were blocking every one of them, reconfigures both bots so future updates arrive grouped, and aligns the Go setup with stacklok/toolhive-registry-server.

Why CI was red

Two independent failures, neither caused by a bad code change — both were hitting every dependency PR:

1. test — TestReplacer_ParseGitHubActionsInFile

The test resolves actions/checkout@v2 against the live GitHub API and asserted the result was ee0669bd…. v2 is a floating major tag, and upstream moved it to 0717577d…, so the assertion broke.

Rather than chase the new SHA (which would break again on the next move), the fixtures now pin to the immutable v2.7.0 tag — ee0669bd… is v2.7.0, so this is the SHA the test always meant. Verified:

v2      -> 0717577d45739eb3c851188b29f50ed6c0b2194e
v2.7.0  -> ee0669bd1cc54295c223e0bb666b733df41de1c5

2. lint — 25 goconst findings

golangci-lint v9 runs goconst over _test.go files, surfacing 25 pre-existing "make it a constant" hits, almost all in table-driven test tables. Enabled goconst.ignore-tests — repeated literals in test tables are idiomatic, not debt.

Note this also cleared the two findings in production code (config.go's "scratch", image.go's "latest"): goconst counts occurrences per-package and ignores strings passed as call arguments, so the test files were supplying the third occurrence that tipped each over the threshold.

Go toolchain setup

Matching stacklok/toolhive-registry-server:

• actions/setup-go v6.5.0 -> v7 (b7ad1dad…, the same SHA toolhive-registry-server pins)
• go-version-file: ./go.mod -> go-version: 'stable' + cache: true, across all six setup-go steps (test.yml x4, codeql.yml, releaser.yml)

The distinction matters: go-version-file pinned CI to exactly what go.mod declares, so CI kept re-proving the code builds on the minimum version. With 'stable', CI builds against the current Go release and go.mod goes back to being purely a floor for consumers.

Note

The go directive stays at 1.26.3 and cannot be a bare 1.26. github.com/moby/buildkit v0.32.x declares go 1.26.3, and Go requires the main module's directive to be >= every dependency's — go mod tidy rewrites 1.26 back to 1.26.3 on sight. buildkit is the only module in the graph asking for more than go1.25.0; holding it at v0.31.0 would allow 1.25.9, which is further from 1.26, not closer. (For reference, toolhive-registry-server also carries a patch component: go 1.26.0.)

Since go.mod no longer drives the CI toolchain, the patch component is now just a floor and doesn't pin anything.

Dependency updates

Where Dependabot and Renovate proposed the same dependency at different versions, the higher one wins.

Go modules

Module	From	To	Closes
github.com/google/go-containerregistry	v0.21.5	v0.21.9	#443, #432
github.com/moby/buildkit	v0.29.0	v0.32.2	#412, #441
github.com/go-git/go-billy/v5	v5.8.0	v5.9.1 (security)	#439, #413
golang.org/x/sync	v0.20.0	v0.22.0	#437
go.mongodb.org/mongo-driver	v1.17.6	v1.17.7	#434

Important

buildkit v0.32.2 moves the go directive 1.25.7 -> 1.26.3. Since pkg/ is a public API surface that other projects import, this raises the minimum Go version for consumers.

buildkit also pulls an unreleased protobuf pseudo-version (v1.36.12-0.20260120151049-…); pinned forward to the released v1.36.12.

GitHub Actions

Action	From	To	Closes
actions/checkout	v6	v7	#440, #428, #427
actions/setup-go	v6.4.0	v7	#436
coverallsapp/github-action	v2.3.6	v2.3.8	#442
github/codeql-action	v4	v4.36.1	#429, #404
golangci/golangci-lint-action	v9	v9.2.1	#423, #422
goreleaser/goreleaser-action	v7	v7.2.2	#420, #418
sigstore/cosign-installer	v4.1.1	v4.1.2	#408, #407

actions/checkout v6 -> v7 is a major. Its breaking change is blocking fork-PR checkout under pull_request_target / workflow_run — neither trigger exists in this repo, so it's a no-op here.

All pins remain SHA-pinned with version comments, and bin/frizbee actions --dry-run --error passes against the result — the tool validates its own workflows.

Bot configuration

.github/dependabot.yml — minor/patch updates now batch into one PR per ecosystem (gomod, github-actions), security updates get their own group, and majors stay ungrouped so a breaking change gets an individual review and can't block the other nine updates in a batch. Schedule moved daily -> weekly, PR limit 5.

No docker / OCI ecosystem entry: this repo has no Dockerfile and .goreleaser.yaml publishes no images, so it would be dead config that just logs "no manifests found". A comment marks where to add it if that changes.

renovate.json — matching groups (go deps, github actions, incl. digest re-pins), weekly schedule, concurrent limit 5.

Warning

Dependabot and Renovate are both enabled and duplicating each other. Of the 21 open PRs, 12 are Renovate and 9 are Dependabot, overlapping almost 1:1 on the same dependencies at different versions — that duplication is the bulk of the noise, and grouping alone won't remove it. I've grouped both so noise drops regardless, but the real fix is picking one. Recommendation: keep Renovate (it handles action digest re-pinning, which fits a SHA-pinning tool) and drop .github/dependabot.yml, or vice versa. Left as a follow-up since it's your call.

Closes

Closes #443, #442, #441, #440, #439, #437, #436, #434, #432, #429, #428, #427, #423, #422, #420, #418, #413, #412, #408, #407, #404

🤖 Generated with Claude Code