alpine: add git for go get goodness

[ruudud]

git is already available in the non-alpine images, and is extremely useful for getting dependencies using the standard tools.

[janeczku]

+1 This is essential

[tianon]

I went back and forth on this several times when I created the image, but I decided against it specifically because the whole point of this image variant is that it's as tiny as possible, so it felt wrong to bloat that for a tool that's often useful but not universally necessary. I believe even "cgo" will require the installation of additional tools. With automated builds (https://docs.docker.com/docker-hub/builds/) and repository links ( https://docs.docker.com/docker-hub/builds/#repository-links) and it's reasonably easy to have an up-to-date image built FROM this one with git and whatever else installed, so it felt like the right compromise, especially since one can use this image entirely without git (for example, if all dependnecies are already vendored in the repo being built).

[ruudud]

Valid points indeed. Should this reasoning be documented somewhere?

I guess it's quite common to want to have git available.

[tianon]

Yeah, I think documenting this is a great idea -- over in https://github.com/docker-library/docs would be the right place (since that's where the image readme comes from), either in ".template-helpers/ variant-alpine.md" or in "golang/content.md" (not sure which would be better, since only the latter is golang-specific).

[janeczku]

yes lets document this. otherwise people will understandably assume that switching dockerfiles from "golang" to "golang:alpine" shouldn't break basic stuff like go get ./....
on another note: do you have plans for an onbuild variant @tianon ?

[tianon]

I wasn't planning on it -- for the slim variants of the various language stacks, we don't bother with an onbuild variant, and not having SCMs installed makes onbuild here kind of pointless (and more likely to break). The way I see the onbuild variant is that it's the jump-start -- it's used to get off the ground running quickly, but eventually more control over the exact Dockerfile instructions is inevitably necessary (need more -dev or otherwise packages installed, etc).

[tianon]

(and I see the alpine variant as essentially a slimmer slim)

[ruudud]

Regarding the docs, I looked into it now. Because of how the README is assembled, I can't really find a suitable place to put Go-Alpine-variant-specific stuff.

.template-helpers/variant-alpine.md should be really generic, right?
Could maybe place an extra sentence there, stating something about additional related tools are most often not included, and that it's common to use it alpine images as a base?

[tianon]

Yeah, something along those lines would be excellent!

[ruudud]

docker-library/docs#413

[CameronGo]

@tianon - sorry for picking up such an old thread, but I was wondering if this might be worth reconsidering. I've only recently begun using alpine images in production and, up to now just use the base golang image for builds and then run the compiled binaries in alpine - no problem. (We build with CGO disabled.)

A new app we're working with; however, makes use of a 3rd party cpp library and so we cannot build with CGO disabled. This is actually a particularly good use case for an alpine prod image b/c I can still add library dependencies here without a bloated ubuntu image.

This seems to require; however, that I do my build an alpine so that I don't run into C library problems when running my CGO enabled app in an alpine prod image. The first step in my jenkins build script; however, is to do a go get, which fails in the golang:alpine image.

Obviously there are numerous workarounds (one of which I will certainly use in the meantime). I am 100% in favor of keeping the golang:alpine image as small as possible, but my feeling is that we should at least have the dependencies installed so that all of the "go" native commands are functional out of the box.

In the meantime I may well just add a the git install to my build script, but I would be interested to see what you think about this after 1 yr+.

[tianon]

@CameronGo don't feel bad -- it's worth revisiting things every now and then!

I'm definitely still of the opinion that git does not belong in the Alpine variant. Adding git adds a full 17MB that downstream users of this image can never reclaim. Additionally, Git is not the only VCS that go get supports -- it's simply the most popular (by a wide margin, sure, but using Go without go get at all is definitely a very supported workflow).

VCSes that go get explicitly supports: (from https://golang.org/src/cmd/go/vcs.go)

• hg (Mercurial)
• git (Git)
• bzr (Bazaar)
• svn (Subversion)