ci: action majors, the Go toolchain switch, and dependabot auto-merge cause 5

[scttfrdmn]

Supersedes and closes #254, #255, #256, #257, #258 — plus three majors Dependabot never proposed.

Why one PR instead of five

Dependabot opened five of these. Five is also open-pull-requests-limit for the github-actions ecosystem, so three further outdated majors were never proposed at all — the queue was saturated. Enumerating every uses: pin against its latest release found them:

action	was	now	Dependabot proposed it?
actions/setup-go	v5	v7	#258
actions/setup-node	v4	v7	#256
actions/setup-python	v5	v7	#254
docker/metadata-action	v5	v6	#257
docker/setup-buildx-action	v3	v4	#255
docker/build-push-action	v5	v7	no
docker/login-action	v3	v4	no
dependabot/fetch-metadata	v2	v3	no

A quiet Dependabot can mean "nothing to do" or "no room to say so." This was the second.

setup-go actually changes behavior

The only bump here with a real mechanism change, so it was traced rather than assumed.

Before (v5): reads the go line → installs go1.26.0. Go's own toolchain switching then downloads go1.26.5 on the first build, because toolchain go1.26.5 says to. The right compiler got used — go version go1.26.5 linux/amd64 in the logs — but it arrived at build time, over the network, once per job. Those tar: ... gotoolchain_local.txt: Cannot open: File exists warnings in every job log are that download racing the module-cache restore.

After (v6+): parses toolchain directly and exports GOTOOLCHAIN=local, so 1.26.5 installs up front and nothing switches. Same compiler, one fewer moving part, no log noise.

Verified against the v7 sources rather than the PR discussion, since the discussion on actions/setup-go#460 records a behavior change that was then partly reverted:

• installer.ts parseGoVersionFile matches /^toolchain go(1\.\d+(?:\.\d+|rc\d+)?)/m and prefers it unless GOTOOLCHAIN is already local
• main.ts calls setGoToolchain(), which sets exactly that — and calls it after resolveVersionInput(), so the toolchain line still wins on the first read

The go.mod comment is updated to describe this, including the new failure mode it introduces: under GOTOOLCHAIN=local there is no safety net — a toolchain version setup-go cannot install now fails the build outright instead of quietly switching to one that works. That is the better behavior for a filesystem, but it should be written down.

The other seven, checked rather than assumed

Each release's removals were grepped for in this repo:

• buildx v4 removed the deprecated config, config-inline and install inputs → not used here
• build-push-action v7 removed DOCKER_BUILD_NO_SUMMARY and DOCKER_BUILD_EXPORT_RETENTION_DAYS → neither appears anywhere in .github/
• setup-python v7 removed the pip-install input → not used
• setup-node v6 limited automatic caching to npm → cannot apply, no cache: input is set on the Node or Python steps
• metadata-action v6 changed # handling inside list values → the tags: list has no # in any value
• all eight require Actions runner ≥ v2.327.1 for their Node 24 runtime, which ubuntu-latest satisfies

One thing found while in here

The sdk-metrics job pinned Node 20, which reached end of life in April 2026 — so CI kept installing a runtime that no longer gets security fixes. sdks/javascript declares node >=16, so nothing was holding the pin down except never having revisited it. Now 22, the active LTS.

Gates

go build ./... · go vet ./... · gofmt -l . clean · go test ./internal/config/ ok (the doc and changelog gates live there). The actions themselves are verified by this PR's own CI running on them.

[scttfrdmn]

Pushed a second commit: cause 5 of the dependabot auto-merge problem (#305), found while this PR was open.

Merging #289 made .github/dependabot.yml valid, Dependabot re-evaluated within minutes, and it opened 14 PRs across ecosystems it had never touched (#290–#303). Every one of them arrived carrying automerge — so the label plumbing genuinely works now, which is the empirical confirmation #288 was missing.

And still nothing merged. The step stopped being skipped and started failing:

failed to create review: GraphQL: GitHub Actions is not permitted to approve pull requests. (addPullRequestReview)
##[error]Process completed with exit code 1.

can_approve_pull_request_reviews is false at the repository level, the step body was gh pr review --approve followed by gh pr merge --auto --squash, and it runs under bash -e — so the failing first line aborted before the line that does the work.

The approval was never needed: branch protection on main requires status checks and has required_pull_request_reviews: null. Deleted the line rather than enabling the permission, which would let every workflow in the repo satisfy a review requirement to buy something no rule asks for.

That is five independent causes for one symptom, and the shape is the useful part — causes 1 and 4 both left the if: condition false, so the step was skipped and this one could not produce a symptom until they were fixed. All five are now enumerated in the workflow header in the order found, with why each hid the next.