Tag request: alpine with git

[JorritSalverda]

Although there's been a number of issues filed on git missing in the alpine images, it would be nice to have a dedicated alpine-git tag that does include git. For runtime the regular alpine image should indeed be kept as small as possible without git installed. But we use the alpine images to build our code and particularly with the new modules system it's very useful to have git installed.

The official docker images have similar tagged image with git preinstalled, see https://hub.docker.com/r/library/docker/tags/.

What do you think? Should be a relatively simple addition from your side, right?

[yosifkit]

We are very reluctant in adding more variations to images since it increases the build times and can delay releases and base image induced rebuilds.

For the docker images it made sense at the time to make a separate tag for adding git. Currently, I'd be more in favor of removing the git version since it is not necessary for the docker cli binary to run and it is for a feature that is rarely used. For reference, the git tag was added in 2015 (docker-library/docker#3).

I still see this as a duplicate of #119, #140, #153, #157, #166, #198, #209, #230, #239, #241, #251.

[david-l-riley]

What's the objection to adding this with apk? Not all environments need git (even for Go), and you're likely to eventually need other customizations to your environment (e.g. gcc and musl-dev if you need cgo to work, protobuf-dev if you need GRPC, etc.). Alpine is intentionally very slim with a good package manager.

[JorritSalverda]

Of course it's possible to install it with apk, which is what I already do. However to save time on every build - I use this image only for building, for the runtime container I use scratch as most people should do if they can - and not need to keep updating my own builder image for every minor release it would be nice for the official image to also have an alpine version with git pre-installed. The regular alpine version should indeed be kept as small as possible.

The reason to require git is really due to the golang toolchain requiring it for commands like go get and the experimental package versioning system. It's essentially a part of golang's package management system and hence it's like creating a node container without npm installed.

In the mean time I'll look at better ways to cache containers locally in my Estafette CI build system so I can use the Debian version instead; now it's just too big and slow to pull in on every build.

Given the fact that there's so many duplicate issues regarding this topic it seems there's popular demand for it, wouldn't you say?

[gsf]

One use case is unit tests. Helps to have a standard image that will run quick.

[tianon]

Ok, let me try to reframe this a little bit.

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 if we add more Alpine-related variants, 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).

As discussed above, adding git to the Alpine variant can currently be accomplished with a very trivial Dockerfile similar to the following:

FROM golang:1.11-alpine3.8
RUN apk add --no-cache git

(On my machine here, the entire apk add instruction completes in ~1 second (real 0m 1.02s), and that's with me bypassing my local download cache to deliberately try and slow it down.)

If the time or bandwidth of running that one-liner is a significant contributor to build time, the Dockerfile above can easily be combined with automated builds (https://docs.docker.com/docker-hub/builds/) and repository links (https://docs.docker.com/docker-hub/builds/#repository-links) on Docker Hub to have an always-up-to-date image built FROM this one with git pre-installed that can be simply pulled instead of built on every invocation with no additional infrastructure setup or maintenance burden.

However, I feel it is worth pointing out that the above downloads ~9MB (from a CDN that's pretty decent, in my experience, with a single HTTP request) vs the resulting compressed layer size, which also comes out to ~9MB (which would come from the Docker Registry, which is more complex than the simple file-based CDN and thus has potentially more failure modes and several HTTP requests). IMO, not a very compelling argument for either the time it takes or the bandwidth it requires vs having users do this (and in my own experience, it installs faster than the layer would even download/extract, given the amount of complexities involved in that whole API through Docker end-to-end vs the simple download+verify+extract of apk add).

So I'm not seeing a strong justification for either the added maintenance burden and appearance of support of an additional variant (which will amount to the two-line Dockerfile I've posted above repeated several times) or the added ~15MB of on-disk size that pre-installing git in the existing variant would bring (which amounts to a ~5% increase in image size).