Missing gcc which is needed to make .test binaries.

[timothysc]

So gcc is needed to make test binaries, and I see in your Dockerfile that you delete it from a builddep dir.

Use case:
go test -i -c -o battery.test github.com/yaddayadda/pkg/battery

The standard golang container works ok, b/c the tooling is installed, but ideally I'd like to use the trim'd alpine containers.

[yosifkit]

Basically a duplicate of #119; specifically #119 (comment):

For many/most users, it isn't necessary, and it cannot be removed after the fact, so we intentionally try to keep the Alpine image as slim as possible.

See also https://github.com/docker-library/docs/blob/7a1edc542ec7d17626ec5cee87e87ed99da71afb/golang/README.md#golangalpine, specifically:

To minimize image size, it's uncommon for additional related tools (such as git or bash) to be 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). 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).

[timothysc]

I disagree with the size vs. usefulness constraint on language/build containers. For runtime containers that makes perfect sense, but this is a language/tooling container. Also, there is not parity in tools needed across the different golang containers.

[khezen]

For many/most users, it isn't necessary, and it cannot be removed after the fact, so we intentionally try to keep the Alpine image as slim as possible.

I disagree with this statement. I believe many/most people would have a multi stage dockerfile in which they would build their binaries using golang:x.x.x-alpinex.x and run the built binary on a slim alpine:x.x. It feels to me that removing the tooling defeats the purpose here.

[tianon]

See also #250 (comment), especially:

I think our image description should probably link directly to golang/go#19938 -- to summarize that thread's current state, Alpine is not actually an officially supported target for the maintainers of Go (it's non-trivial enough to get the test suite passing on Alpine that we're coming up on two years since it was first attempted in earnest).

The reason this is relevant here is that ... I'm afraid it will lend more to the appearance of Alpine being something not only supported, but potentially even recommended by the Go team, which is definitely not accurate (and if we had a clean way to de-emphasize our current Alpine variants until that issue is resolved and upstream officially supports it, I would definitely be considering it).

[goku321]

I am using golang:alpine as my docker image(go version 1.13.5) and there's no gcc. I had to install it manually.

[Freyert]

Doing a RUN apk add build-base adds about 207 MB to alpine so you're not really that much better off using it.

It makes more sense to build using a more well supported distro and just copying into the slim version of that distro. Debian's slim distro is typically around 27MB which is less than the golang version because believe it or not golang is a pretty big install.

Not sure you can really get below 150MB for an image that compiles golang binaries. Alpine linux provides sort of a "false" benefit. If you're going for small you might as well use a scratch container and run just your binary.