fix: set go module directive to 1.22.0 #1878
Conversation
The go directive sets the minimum version of Go required to use this module. There's no need to set this to the latest semver patch version of a given Go release unless the semantics of that version of Go are required to build/test/use the module. Notably since PR sigstore#1865 any consumers of sigstore as a library would need to bump their own go directive to 1.22.8 in order to pickup the sigstore 1.8.10 release. Ref: https://go.dev/ref/mod#go-mod-file-go Signed-off-by: Dominic Evans <[email protected]>
| @@ -1,6 +1,6 @@ | |||
| module github.com/sigstore/sigstore | |||
|
|
|||
| go 1.22.8 | |||
| go 1.22.0 | |||
There was a problem hiding this comment.
we will need to update places like https://github.com/sigstore/sigstore/blob/main/.github/workflows/e2e_test.yml#L37C1-L37C34 to pin to 1.22 or 1.23 otherwise it will install the 1.22.0 only and i think we want to use the latest available always
There was a problem hiding this comment.
Good spot, pushed up d8cb131 as a suggestion of how to address that
There was a problem hiding this comment.
Caveat: I'm not an expert on Go version resolution
The reason we began to include the patch release version is because the tooling required us to either set the specific version of Go or add a toolchain directive. When @cpanato started moving us to 1.23, it seemed like something changed in the tooling and we didn't need to specify the patch version, only the minor version like what we used to do.
If it is possible to only specify 1.22 or 1.23, let's do that. I'd rather not have the complexity of CI tooling pulling a different version than what's in the go.mod file.
There was a problem hiding this comment.
Certainly you can't use go 1.22 in go.mod, in recent go1.22.x versions they'll just complain that go.mod needs tidying and will update it to 1.22.0 and also add a toolchain go1.22.8 directive:
% grep -E '^(go|toolchain)' go.mod
go 1.22
% go1.22.8 build ./...
go: updates to go.mod needed; to update it:
go mod tidy
% go1.22.8 mod tidy
% grep -E '^(go|toolchain)' go.mod
go 1.22.0
toolchain go1.22.8
There was a problem hiding this comment.
Something does seem to have changed in 1.23 whereby '1.23' is seemingly accepted as a directive again
% grep -E '^(go|toolchain)' go.mod
go 1.23
% go1.23.2 build ./...
% go1.23.2 mod tidy
% grep -E '^(go|toolchain)' go.mod
go 1.23
There was a problem hiding this comment.
The change in behaviour in 1.23 is referenced in this comment on this well-cited GH issue on the confusion around the go directive changes:
However, that's really saying that go itself will just silently assume 1.23.0 for module requirements and toolchain rather than the more useful 1.23.X.
Unfortunately from a GitHub Actions perspective, setup-go doesn't currently know or use go toolchain versions, it's just manually parsing the go.mod for 'go' directives itself and hasn't really kept up with the 1.22 and 1.23 changes here. There's an issue tracking that over here
There was a problem hiding this comment.
thank you @dnwe for all the clarification TIL a lot about this fuzzy thing that i cant understand
There was a problem hiding this comment.
Thanks for digging into this!
Instead of using setup-go's built-in go-versions-file behaviour, grab the MAJOR.MINOR directive from go.mod manually and use that as input to request the latest `.PATCH` variant from setup-go Signed-off-by: Dominic Evans <[email protected]>
Signed-off-by: Dominic Evans <[email protected]>
Summary
The go directive sets the minimum version of Go required to use this module. There's no need to set this to the latest semver patch version of a given Go release unless the semantics of that version of Go are required to build/test/use the module.
Notably since PR #1865 any consumers of sigstore as a library would need to bump their own go directive to 1.22.8 in order to pickup the sigstore 1.8.10 release.
Ref: https://go.dev/ref/mod#go-mod-file-go
Fixes #1879
Release Note
None
Documentation
N/A