golang: Missing package in 1.18
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.
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Comments: 15 (5 by maintainers)
Commits related to this issue
- Set `buildvcs` to false See https://github.com/docker-library/golang/issues/415#issuecomment-1069703747 — committed to pivotal-cf/shared-redis-release by JulianBenitez99 2 years ago
- Add `-buildvcs=false` to `go build` in Dockerfile See docker-library/golang#415 Signed-off-by: AKP <tom@tdpain.net> — committed to codemicro/walrss by codemicro 2 years ago
- Use necessary files only This improves cache hits and avoid this: https://github.com/docker-library/golang/issues/415 — committed to misery/HeatingMqttBridge by misery 2 years ago
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):
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.
If you really don’t need
.gitfor your builds at all, you can add.gitto.dockerignoretoo 👀Here’s a simple reproduction:
As it says, running
go build -buildvcs=false .fixes it. Deleting.gitalso fixes it.It looks like the new VCS status embedding feature in go 1.18 requires git, and instead of silently skipping buildvcs when
gitisn’t available, it shows an error.@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.
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.
I went back to 1.17.8 and confirmed that there’s no
gitanywhere on the image filesystem. So I’m not sure what was actually broken.