英文:
Why does docker build fail in a newly-initialized git repo?
问题
docker build 在新初始化的 git 仓库中运行时为什么会失败/警告？
$ mkdir dockergit
$ cd dockergit
$ git init
Initialized empty Git repository in /home/user/projects/foo/dockergit/.git/
$ cat << EOF > ./Dockerfile
> FROM alpine:3.7 as base
> EOF
$ docker build -t tmp:tmp .
[+] Building 0.2s (5/5) FINISHED
=> [internal] load .dockerignore 0.1s
=> => transferring context: 2B 0.0s
=> [internal] load build definition from Dockerfile 0.1s
=> => transferring dockerfile: 61B 0.0s
=> [internal] load metadata for docker.io/library/alpine:3.7 0.0s
=> [1/1] FROM docker.io/library/alpine:3.7 0.0s
=> exporting to image 0.0s
=> => exporting layers 0.0s
=> => writing image sha256:a3b9ee7f5e9bf7ad39ad1e9893be65001bd6367c7d10e2a682985d03e46458a9 0.0s
=> => naming to docker.io/library/tmp:tmp 0.0s
WARNING: buildx: failed to get git commit: fatal: ambiguous argument 'HEAD': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
$
$ git --version
git version 2.11.0
$ docker --version
Docker version 23.0.0, build e92dd87
更新：针对“HEAD 不存在”的评论：我不理解的是为什么 docker build 与 git 之间会有任何交互。也就是说，为什么 docker build 会尝试/触发与 git 有关的任何操作？
英文:
Why does docker build fail/warn when run in a newly-initialized git repo?
$ mkdir dockergit
$ cd dockergit
$ git init
Initialized empty Git repository in /home/user/projects/foo/dockergit/.git/
$ cat << EOF > ./Dockerfile
> FROM alpine:3.7 as base
> EOF
$ docker build -t tmp:tmp .
[+] Building 0.2s (5/5) FINISHED
=> [internal] load .dockerignore 0.1s
=> => transferring context: 2B 0.0s
=> [internal] load build definition from Dockerfile 0.1s
=> => transferring dockerfile: 61B 0.0s
=> [internal] load metadata for docker.io/library/alpine:3.7 0.0s
=> [1/1] FROM docker.io/library/alpine:3.7 0.0s
=> exporting to image 0.0s
=> => exporting layers 0.0s
=> => writing image sha256:a3b9ee7f5e9bf7ad39ad1e9893be65001bd6367c7d10e2a682985d03e46458a9 0.0s
=> => naming to docker.io/library/tmp:tmp 0.0s
WARNING: buildx: failed to get git commit: fatal: ambiguous argument 'HEAD': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
$
$ git --version
git version 2.11.0
$ docker --version
Docker version 23.0.0, build e92dd87
Update: Addressing the comments that "HEAD doesn't exist yet": what I don't understand is why there's any interaction between git and docker at all. I.e. why is docker build trying to/triggering anything related to git?
答案1
得分: 1
This particular bug was fixed in pull request 1592 though whether your buildx is up to date with that is questionable since it was only merged to master three weeks back (as at the time this question was asked).
这个特定的错误已经在 pull request 1592 中修复，但你的 buildx 是否已经更新到这个版本尚不确定，因为它是在三周前才合并到 master 分支的（截至提问时）。
And the first release containing that PR was 0.10.3, released on Feb 16, 2023 (roughly ten days ago, again as at the time of this question).
包含这个 PR 的第一个 发布版本 是 0.10.3，于 2023 年 2 月 16 日发布（大约是十天前，同样是在提问时）。
Until it is up to date, I'd suggest you just ensure you always have a HEAD so this warning doesn't happen.
在它更新到最新版本之前，我建议你始终保持有一个 HEAD，以防止出现这个警告。
Addressing your update about why docker and git are interacting, it's to provide useful information to the build environment should you wish to use it. See here for the git.go file, which shows the items extracted, such as labels, the commit point, whether state is dirty (changed files after commit point), and so on.
针对你关于 为什么 docker 和 git 会互动的更新，这是为了在构建环境中提供有用的信息，如果你愿意使用它的话。可以查看这里的 git.go 文件，其中显示了提取的项目，如标签、提交点、状态是否脏（在提交点之后更改的文件）等等。
For example, we like to bake the commit point into the application and log it on startup, so we know exactly what software is running when a bug report rolls in.
例如，我们喜欢将提交点嵌入应用程序中，并在启动时记录它，这样当出现 bug 报告时，我们就能知道确切地运行了哪个软件。
Issue 1290 was the one that brought this git.go file into existence, there's a far more detailed explanation there, including the text:
问题 1290 是引入了 git.go 文件的问题，那里有更详细的解释，包括以下文本：
> Therefore, we'd like to propose that buildx starts to record the following pieces of provenance when being run with a context that has a .git directory:
> - Git commit SHA of current checked out HEAD.
> - Include flag to indicate state of local clone (dirty).
> - Dockerfile path.
> 因此，我们建议在具有 .git 目录的上下文中运行时，buildx 开始记录以下来源的部分：
> - 当前已检出 HEAD 的 Git 提交 SHA。
> - 包括指示本地克隆状态的标志（脏）。
> - Dockerfile 路径。
英文:
This particular bug was fixed in pull request 1592 though whether your buildx is up to date with that is questionable since it was only merged to master three weeks back (as at the time this question was asked).
And the first release containing that PR was 0.10.3, released on Feb 16, 2023 (roughly ten days ago, again as at the time of this question).
Until it is up to date, I'd suggest you just ensure you always have a HEAD so this warning doesn't happen.
Addressing your update about why docker and git are interacting, it's to provide useful information to the build environment should you wish to use it. See here for the git.go file, which shows the items extracted, such as labels, the commit point, whether state is dirty (changed files after commit point), and so on.
For example, we like to bake the commit point into the application and log it on startup, so we know exactly what software is running when a bug report rolls in.
Issue 1290 was the one that brought this git.go file into existence, there's a far more detailed explanation there, including the text:
> Therefore, we'd like to propose that buildx starts to record the following pieces of provenance when being run with a context that has a .git directory:
>
> - Git commit SHA of current checked out HEAD.
> - Include flag to indicate state of local clone (dirty).
> - Dockerfile path.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论