gopin

Overview ¶

Command gopin replaces `go-version: stable` in a repository's workflows with an explicit version, and raises go.mod to match.

WHY AN ALIAS IS THE DEFECT ¶

`stable` is a channel, not a version. Three things follow, all measured on go-pkgx on 2026-10-04 before this was written:

• The toolchain moves with no commit. CI was building and running on go1.27.1 — `Setup go version spec stable` / `go version go1.27.1` in the job log — while every go.mod in the organisation still said `go 1.26.4`. A MINOR Go bump reindents under gofmt and changes coverage block counting, and that one arrived with nothing to review.

• A Renovate rule written for exactly this cannot act. The go-pkgx preset matches dep name `go` under the `gomod` and `github-actions` managers with `automerge: false` and `groupName: null`, citing golang/go#81000. It had never produced a pull request, because there was no version to compare or rewrite.

• The contrast is demonstrable, not argued. In ONE ci.yml, go-pkgx/registry-viewer, the `build` job said `stable` and Renovate did nothing; the `bricolint` job said "1.26.4" and Renovate opened a pull request to move it to 1.27.1. Same file, same run, one variable.

So pinning is not rigidity: it is the condition for the review rule to apply at all.

WHY IT READS THE API AND NEVER A LOCAL CHECKOUT ¶

A local clone is a claim about whenever it was last fetched. On the day this was written a local sweep still reported three go-pkgx repositories as asking for `stable` hours after all eight had been pinned and merged. Every read here is of the default branch as GitHub holds it.

WHAT IT REFUSES TO DO ¶

It will not touch a job that already names a concrete version, even an old one. Somebody chose that, possibly to hold a repository back, and silently moving it is the opposite of what this tool is for. It reports those instead.