Include `git` or otherwise address "current commit information was not captured by the build: git was not found in the system: ..."

[eriksw]

When I use the docker image as a build step in Google Cloud Build to perform buildx builds, I get the following warning:

WARNING: current commit information was not captured by the build: git was not found in the system: exec: "git": executable file not found in $PATH

I presume this has to do with provenance being enabled by default per https://docs.docker.com/build/attestations/slsa-provenance/#mode

I would like to be able to use the docker image to run docker buildx ... and have the provenance information captured as designed by the new default. I know about the option to suppress the warning by using BUILDX_NO_DEFAULT_ATTESTATIONS=1 to disable the feature entirely, but I would prefer to get it working instead.

As an end user I have no preference between what I presume are the two possible solutions:

1. Modify the provenance feature to extract the required information without running git as a child process.
2. Add git to the docker image.

(I'm opening this issue here because I presume the second option is much more reasonable to implement.)

[eriksw]

Additional context:

Unlike CI/CD environments like GitHub Actions where you could have an apt-get install git step make git available to later docker buildx ... steps, in Google Cloud Build every step (including invocation of docker) happens in a new docker container of the step's specified image, with only specific shared mounts being available to persist/pass artifacts and state between steps.

To work around the lack of git in the upstream docker image by adding it in to steps that run buildx, you'd wind up doing something equivalent to docker run ... docker /bin/bash -c "apt-get update; apt-get install git; docker buildx ..." for every "run docker" step in the build definition.

[whalelines]

The docker:git image includes the git package. Please try using that tag.

[eriksw]

That does work, thank you for pointing it out.

I guess there remains an open question of whether it's appropriate for the default to not include git, given the dependency on it added upstream. In other words: should 'docker' and 'docker:git' be made the same?

[tianon]

I did some research to remember why I split these originally because I remember vaguely that it was effectively "because Git is big" but that didn't seem true anymore.

Well, it turns out Git's size isn't the thing that changed (well, it did, but it's still in the same ballpark). The real justification could be more accurately stated as adding Git was a non-trivial increase in the total image size as compared to without it -- in other words, it's not that Git's smaller now, but rather that Docker (and buildx, compose, and now separated CLI/engine which used to be a single static binary) are now so much bigger than they used to be that 5 or even 10 MiB seems pitiful now.

We added the Git variant in 2724961, at Docker 1.6.0. At the time, the base Alpine image was 2.5MB, the Docker binary (yes, singular) was 4.7MB, and Git+SSH was a whopping 8.8MB, so this seemed like a pretty reasonable line to draw ("the Git layer is bigger than the entire image without it, including the distro!"). Even the extra dind deps at the time were only 2.5MB (so 8.8MB was truly "big" in comparison)!

Fast forward to 2024 with Docker 25.0.3, and Alpine is 3.4MB, then we add SSH all the time now (7a67842, with some familiar echos in it) which is ~2MB when combined with ca-certificates too, then 17MB of the Docker CLI binary, 17MB of the buildx binary, 18MB of the Compose binary, 7.1MB of engine dependencies, and a whopping 56MB(!!!!) of the Docker Engine binary. Adding an extra 5.1MB for Git to that feels almost free? (It's still a bigger size increase than I'm thrilled about, but I'm definitely willing to consider it.)

In other words, golang/go#6853 😭

[jnoordsij]

When looking through my (GitLab) build logs I ran into this and figured that #483 does not exactly solve this: it looks like this message requires the git binary within the cli variant rather than within the dind variant.

As an example, I set up a very minimal GitLab repo using a reduced version of GitLab's example Docker CI template to build a Hello World image. This results in the build reporting the aforementioned warning, which is not present when dind is also used to build the image (see https://gitlab.com/jnoordsij/test-docker-ci/-/jobs/7215262223).

Therefore I was wondering:

• Is a follow-up to Add git to dind variants (and make git an alias of dind, for 24.x and 25.x) #483, moving the git install from dind to cli, appropriate? This might once again boil down to size comparison?
• Or should instead GitLab's template be updated to use dind both as service and image? This feels a bit off to do, but given we're already pulling in the larger dind image, this probably is not an issue? Or is there some dind entrypoint logic that might hurt performance in some way?

Note: if this should be (re-)opened and/or discussed elsewhere, let me know!

[tianon]

Oof, yep, looks like Git is indeed appropriate in both CLI and DinD now. 😞

Edit: sorry, to expand on that, but still in a terse way: docker build . / docker buildx build . might shell out to git to ask about the context directory's git status, DOCKER_BUILDKIT=0 docker build https://example/foo.git will run git in the client context, and docker buildx build https://example/foo.git will run git in the daemon context