-
Notifications
You must be signed in to change notification settings - Fork 508
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
proposal: set GOTOOLCHAIN=local (or =path) in our image #472
Comments
@rsc I really hope you don't mind being pinged for your opinion (or help directing to the right folks for an opinion) on how we can best represent Go here; I've tried to make sure this has enough information for you help guide us without having to be totally well versed in how Go is commonly used in containers (just in case you aren't) ❤️ 😅 🙇 One of our highest goals in maintaining this image is to appropriately represent Go upstream in the way we believe they might represent themselves (https://github.com/docker-library/official-images/tree/78bad2f7ead1688af35d768fa1a23939fff77f89#what-are-official-images, bullet point 5). We're obviously not perfect at this (or balancing this with end user expectations/desires), but we do try very hard to do so unobtrusively. This has come up most recently in the context of We do not want or intend to reopen those debates (and any unproductive comments attempting to do so here will be hidden as off topic), but we do think the way that users interact with this image currently perhaps does warrant a change in that default behavior. Typically, users of this image will have a FROM golang:X.Y
# or
FROM golang:X.Y.Z
# ...
COPY my-code /some/path
RUN go build ... As you can see, there is usually a very clear user intent that they desire Go version X.Y (or X.Y.Z), and the argument here is that it would be very surprising if a In short, the proposal is that we should set Any thoughts or opinions you might be willing to share would be deeply appreciated!! 🙇 |
I am in favor of at least setting |
It seems to me that it would be best to leave it at the default GOTOOLCHAIN=auto. If you set GOTOOLCHAIN=local, then in the cases where a download would have happened, |
I strongly object to As the base image is rebuilt regularly, a Especially in CI/semi-automated environments [scripts] (a large part of the use case for this base image), automatically upgrading the toolchain instead of failing early and informing the user what is wrong severely violates the principle of least surprise for me. |
In that case, setting GOTOOLCHAIN=local makes sense. |
Related discussion in docker-library/golang#472 Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Related discussion in docker-library/golang#472 Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Related discussion in docker-library/golang#472 Signed-off-by: Sebastiaan van Stijn <github@gone.nl> (cherry picked from commit aa28297) Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Many belated thanks for your time/thoughts, Russ -- it's really appreciated (as is your upstream work) ❤️ |
Force `go` to always use the local toolchain (i.e. the one the one that shipped with the go command being run) via setting the `GOTOOLCHAIN` environment variable to `local`[1]: > When GOTOOLCHAIN is set to local, the go command always runs the bundled Go toolchain. This is how things are setup in the official Docker images (e.g.[2], see also the discussion around that change[3]). The motivation behind this is to: * Reduce duplicate work, the action will install a version of Go, a toolchain will be detected, the toolchain will be detected and then another version of Go installed * Avoid Unexpected behaviour: if you specify this action runs with some Go version (e.g. `1.21.0`) but your go.mod contains a `toolchain` or `go` directive for a newer version (e.g. `1.22.0`) then, without any other configuration/environment setup, any go commands will be run using go `1.22.0` * TODO: link image This will be a **breaking change** for some workflows. Given a `go.mod` like: module proj go 1.22.0 Then running any `go` command, e.g. `go mod tidy`, in an environment where only go versions before `1.22.0` were installed would previously trigger a toolchain download of Go `1.22.0` and that version being used to execute the command. With this change the above would error out with something like: > go: go.mod requires go >= 1.22.0 (running go 1.21.7; GOTOOLCHAIN=local) [1] https://go.dev/doc/toolchain#select [2] https://github.com/docker-library/golang/blob/dae3405a325073e8ad7c8c378ebdf2540d8565c4/Dockerfile-linux.template#L163 [3] docker-library/golang#472
Note: we need to set toolchain to auto just for installing tools. We want to keep the image default of local for CI and fail if a dependency tries to update the go version. Ref: docker-library/golang#472
Per https://go.dev/doc/toolchain, it might make sense for us to set
GOTOOLCHAIN=local
(or evenGOTOOLCHAIN=path
) by default in our images. I'll follow this up with a comment describing more long-form why I think this might be appropriate here, but wanted to get an issue open where it can be discussed properly.The text was updated successfully, but these errors were encountered: