Skip to content
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

Missing package in 1.18 #415

Closed
ocket8888 opened this issue Mar 16, 2022 · 15 comments
Closed

Missing package in 1.18 #415

ocket8888 opened this issue Mar 16, 2022 · 15 comments

Comments

@ocket8888
Copy link

golang:1.17.8-alpine came with the git executable - presumably to accommodate go get - but golang:1.18-alpine does not - presumably because of the breaking change to go get that accompanied the new version.

@yosifkit
Copy link
Member

yosifkit commented Mar 16, 2022

git in the PATH? It is not installed in the alpine based image on purpose (and never has been).

Duplicate of #345/#347 (most recently), but see also #250 (comment); #119, #140, #153, #157, #166, #198, #209, #230, #239, #241, #251, #328.

@ocket8888
Copy link
Author

I have an image that worked using golang:1.17.8-alpine and now fails to build an executable at runtime having changed only that base image with:

go: missing Git command. See https://golang.org/s/gogetcmd
        error obtaining VCS status: exec: "git": executable file not found in $PATH
 	Use -buildvcs=false to disable VCS stamping.

I assumed this was because git used to be in the $PATH, but it could just be a misleading error message

@ocket8888
Copy link
Author

I went back to 1.17.8 and confirmed that there's no git anywhere on the image filesystem. So I'm not sure what was actually broken.

@ocket8888
Copy link
Author

Found the exact command in the image's CMD that used to work but now doesn't:

go build --gcflags "all=-N -l" .

a go build that used to work no longer does

@dagood
Copy link
Contributor

dagood commented Mar 16, 2022

Here's a simple reproduction:

docker run -it --rm golang:1.18-alpine sh -c '
  mkdir /app; cd /app
  echo "package main;func main(){}" > main.go
  go mod init example
  mkdir .git
  echo ---
  go build .'
go: creating new go.mod: module example
go: to add module requirements and sums:
        go mod tidy
---
go: missing Git command. See https://golang.org/s/gogetcmd
error obtaining VCS status: exec: "git": executable file not found in $PATH
        Use -buildvcs=false to disable VCS stamping.

As it says, running go build -buildvcs=false . fixes it. Deleting .git also fixes it.

It looks like the new VCS status embedding feature in go 1.18 requires git, and instead of silently skipping buildvcs when git isn't available, it shows an error.

@ocket8888
Copy link
Author

But that's impossible, the Go team knows that it's unacceptable to ever make a breaking change under any circumstances 🙄

More seriously it looks from that bottom comment like they're open to fixing this - but at any rate it's not an issue with this Docker image, but an upstream problem. I'll take it up with them. Thanks.

@tianon
Copy link
Member

tianon commented Mar 16, 2022

If you really don't need .git for your builds at all, you can add .git to .dockerignore too 👀

@abursavich
Copy link

@ocket8888, please consider re-opening this issue.

There is a new std package in go 1.18, debug/buildinfo, which requires git in order to stamp the version control info on the binary (svn, hg, and bzr might be required too?). It's unfortunate that this may unnecessarily break some use cases (e.g. tests), but I think it's reasonable to expect that the official docker image should support the std packages of the language.

@ocket8888
Copy link
Author

ocket8888 commented Mar 17, 2022

If you really don't need .git for your builds at all, you can add .git to .dockerignore too 👀

No, the source directory is mounted as a volume, not loaded into the build context, so that's unfortunately not an option.

It's unfortunate that this may unnecessarily break some use cases (e.g. tests), but I think it's reasonable to expect that the official docker image should support the std packages of the language.

I'll re-open if you want, but for the record I think Go ought to walk this back instead. And they yet might. No idea how long that would be, though, or if 1.18.0 would ever see it anyway.

@codemicro
Copy link

I'll re-open if you want, but for the record I think Go ought to walk this back instead.

The Go team is adding a -buildvcs=auto option that'll be backported to 1.18 that will implicitly disable VCS stamping if no VCS can be found.

@abursavich
Copy link

abursavich commented Apr 8, 2022

It'll be great if VCS binaries are not a hard dependency of the go tool, but I still think they should still be present in the official golang 1.18+ images.

@ocket8888
Copy link
Author

They probably should be. Otherwise it's a feature of the tool for which the image is built that isn't directly supported by that image. Which is unusual. You could add -no-vcs suffix tags for every version from now on, but that seems like a lot of work and I'd wager hardly any users would actually switch to it.

@tianon
Copy link
Member

tianon commented Apr 11, 2022

The non-Alpine (Debian-based) images do contain all the tools -- they're FROM buildpack-deps:XXX-scm, which already includes most of the SCMs from https://github.com/golang/go/wiki/GoGetTools (by design).

Quoting again from the Alpine section of https://hub.docker.com/_/golang (https://github.com/docker-library/docs/tree/0b63293e37969498f85b48a9bcb5908993052ddc/golang#golangversion-alpine):

This variant is highly experimental, and not officially supported by the Go project (see golang/go#19938 for details).
...
To minimize image size, additional related tools (such as git, gcc, or bash) are not included in Alpine-based images. Using this image as a base, add the things you need in your own Dockerfile (see the alpine image description for examples of how to install packages if you are unfamiliar). See also docker-library/golang#250 (comment) for a longer explanation.

The Alpine variants exist specifically to be much smaller than the default base, not to be a full-featured 100% complete environment ready-for-use like the non-Alpine variants are.

@ocket8888
Copy link
Author

Fair enough.

misery added a commit to misery/HeatingMqttBridge that referenced this issue May 6, 2022
This improves cache hits and avoid this:
docker-library/golang#415
@tianon
Copy link
Member

tianon commented Jun 13, 2022

(Closing per #415 (comment) ❤️)

@tianon tianon closed this as completed Jun 13, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants