New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
toolchain: directive in go.mod being updated unnecessarily #65847
Comments
Please fill out the complete issue template. In particular: what version of Go are you using, what was your |
@bcmills updated - can you take a look again and see if I'm missing anything? |
Adding my own experiences for reference. At work, we would definitely prefer to have the ability to disable the automatic toolchain upgrades (and possibly fail builds that would otherwise require a newer toolchain). We have many modules with the This feature started causing issues for us when one engineer using Go 1.21.x locally updated some dependency and ran Without the ability to opt out of automatic toolchain upgrades we are now forced to synchronize the Go version across CI and every developer machine. While that's not an unreasonable stance in the general case, it is a new restriction/requirement that, as far as I've seen, is not called out in the release notes. We have tried setting One could also argue that forcing more conservative development shops to always stay on the most current Go release, despite the previous minor release being explicitly supported, is a bad situation. |
As of Go 1.21, the initial toolchain release has a And for the Some specifics:
|
You do have that ability: you can set You can also force
That is exactly the problem that |
This works, but it also means that as soon as anyone moves to a newer Go release then everyone else in the organization must also move to that same newer version immediately. This is a problem in tightly regulated environments where, as an example Go 1.22.x may not be "certified" but Go 1.21.5 is. As it stands today it's not possible to both fix CI to 1.21.x and also allow developers to use a newer 1.21.y or 1.22.
TIL. Thanks for this. |
There are environments where setting an env. var. is not possible. For example, the public Renovate service does not support this. There are other ways to pin the golang version in Renovate, but they're undesirable for maintainability reasons. Devcontainers could be another example, where the tooling env. is shared, and must remain static, for consistency across a whole team of developers. In any case, my point is there are places where setting env. vars. isn't a viable workaround. IMHO such major behavior changes should almost always default to the previous or "least disruptive" option. |
There doesn't seem to be a way to stop the
toolchain
directive from being updated when running variousgo
commandsIn our OSS project we rely on the
go
directive in the go.mod to ensure a min go version. We do not want to use thetoolchain
directive as we always expect it to match thego
directive.some user feedback
Go Version
Go ENV
expand
Scenario 1 - creating a new module and downgrading go
What did you do
What did you see happen?
What did you expect to happen?
toolchain
directive to be added1.21
- since I didn't specify the point releaseScenario 2 - pulling a new dependency that upgraded the go version
What did you do
Project structure
Fetch a dependency that updates the go min version
What did you see happen?
console output
go.mod output
What did you expect to happen?
toolchain
directive shouldn't appear. We want it to always default to the same as thego
directiveThe text was updated successfully, but these errors were encountered: