ci: define the Go toolchain once, and put it back on 1.22 - #467
Merged
Conversation
4a49804 set Go 1.26 "for lint job so golangci-lint v2 builds" and changed the wrong job: the version it edited belongs to "build and test", while lint kept 1.22 and has been passing on it ever since. So the bump fixed nothing and left one of three jobs compiling and testing on a different toolchain from its neighbours. That is the failure mode worth removing. A construct accepted by 1.26 and rejected by 1.22 would surface as one job disagreeing with the others for reasons unrelated to the change under test — and the job that disagreed would be the one running the tests. Every other declaration in the repository says 1.22: go.mod is go 1.22.2, the Dockerfile builds FROM golang:1.22-alpine, and README.md and CONTRIBUTING.md both promise "Go 1.22+". CI now says the same thing, in one place, so the next edit cannot move one job without the others. Raising the supported version is a separate decision. It would touch go.mod, the Dockerfile and both documents together, and it should be taken on its own rather than arriving as a side effect of a lint fix.
This was referenced Sep 1, 2026
Israel-light
added a commit
to Israel-light/wayfare
that referenced
this pull request
Sep 2, 2026
…lized Go version The branch's ci.yml was missing the merge_group trigger and centralized GO_VERSION env variable that upstream added in Wayfare-labs#467 and Wayfare-labs#468. Syncing to match upstream while keeping all branch-specific code changes. 🤖 Generated with Codebuff Co-Authored-By: Codebuff <noreply@codebuff.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Makes
maininternally consistent about which Go toolchain CI uses, and stops it drifting again.The bug
4a49804is titled "ci: use Go 1.26 for lint job so golangci-lint v2 builds" — but the line it changed belongs to build and test, not lint:Lint has been passing on 1.22 throughout, so the bump achieved nothing and left one of three jobs compiling and running the test suite on a different toolchain from its neighbours.
That matters because it is silent: a construct accepted by 1.26 and rejected by 1.22 shows up as one job disagreeing with the others for reasons unrelated to the change under test — and the disagreeing job is the one running the tests.
The fix
One
env: GO_VERSIONat workflow level, referenced by all threesetup-gosteps. The next edit cannot move one job without the others.Why 1.22 and not 1.26 — every other declaration in the repository already says 1.22:
go.modgo 1.22.2DockerfileFROM golang:1.22-alpineREADME.mdCONTRIBUTING.mdRaising the supported version is a real decision, but it touches
go.mod, the Dockerfile and both documents together. It should be taken deliberately, not inherited from a misapplied lint fix.Side effect worth knowing
#436 and #437 both carry this same one-line change. Once this lands, their
ci.ymlhunk becomes a no-op — which removes the fork-PR-touches-workflow escalation on both, so they can be judged on their actual contents instead.