Update to go 1.22 #5715
Update to go 1.22 #5715
Conversation
Signed-off-by: Paul Holzinger <[email protected]>
The fedora version where wrong in the name causing the task names to show the wrong distro versions. Signed-off-by: Paul Holzinger <[email protected]>
The golang version is not new enough, this needs to be turned back on when we upgrade VMs to f41/40 so it is only commented out. Signed-off-by: Paul Holzinger <[email protected]>
Fedora 39 and epel 9 contains go 1.21 which we no longer build on, fedora 39 will likely never be updated but epel 9 should get a golang update at some point. Signed-off-by: Paul Holzinger <[email protected]>
|
@edsantiago @nalind PTAL |
|
LGTM |
| @@ -1,21 +1,8 @@ | |||
| module github.com/containers/buildah | |||
|
|
|||
| // Minimum required golang version | |||
| go 1.21.0 // ***** ATTENTION WARNING CAUTION DANGER ****** | |||
| // Warning: Ensure the "go" and "toolchain" versions match exactly to prevent unwanted auto-updates | |||
There was a problem hiding this comment.
Will it be obvious to future maintainers what "toolchain" means? The string "toolchain" does not appear anywhere else in this file. My guess was, this means test/tools/go.mod, but that file has go 1.21
There was a problem hiding this comment.
It is the same comment we have in podman and c/common and yes a go dev should now what these mean I would say, https://go.dev/doc/modules/gomod-ref#toolchain
Though I am happy to alter this comment to something else that makes it more clear, generally speaking we never want toolchain to be newer than the go version and it seems at some point the go vendor process decided to not add toolchain if it matches the exact go version, i.e. if we try to add toolchain go1.22.0 make vendor removes it again. Only if you have something like toolchain go1.22.1 it stays but this is not something we want.
So I guess we should simplify this comment and say we never ever want a toolchain directive in this file.
There was a problem hiding this comment.
Can you merge this for now?
I have some outstanding discussions around the handling of patch versions in the go line with @mtrmac so I like to wait for whatever we decide on and then update the comments based on that
|
/lgtm |
|
/approve |
|
Looks like I don't have approve privs in this repo |
|
/approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: edsantiago, Luap99, rhatdan The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
What type of PR is this?
/kind other
What this PR does / why we need it:
Update golang so we can keep updating dependecies
How to verify it
Which issue(s) this PR fixes:
Special notes for your reviewer:
Does this PR introduce a user-facing change?