这种行为是由docker或podman使用的上下文目录来呈现文件给构建过程的。
这里有一个很好的技巧，在构建指令中将上下文目录更改为要暴露给守护程序的目录的完整路径。例如：
docker build -t imageName:tag -f /path/to/the/Dockerfile /mysrc/path
使用 /mysrc/path 代替 .(当前目录)，你将会以该目录为上下文，因此构建过程可以看到该目录下的所有文件。
在这个例子中，你将会向docker daemon暴露整个/mysrc/path树。
当与docker一起使用时，触发构建的用户ID必须对上下文目录中任何单个目录或文件具有递归读取权限。
在以下情况下，这可能非常有用：你有一个/home/user/myCoolProject/Dockerfile，但希望将不在同一目录中的文件引入到该容器构建上下文中。
这里提供一个使用上下文目录进行构建的示例，但这次使用的是podman而不是docker。
假设你的Dockerfile中有一条COPY或ADD指令，将要从项目外部的一个目录中复制文件，如下所示：
FROM myImage:tag
...
...
COPY /opt/externalFile ./
ADD /home/user/AnotherProject/anotherExternalFile ./
...
为了构建这个项目，需要使用位于
/home/user/myCoolProject/Dockerfile路径下的容器文件，只需执行以下操作：
cd /home/user/myCoolProject
podman build -t imageName:tag -f Dockefile /
一些已知的更改上下文 dir 的用例是在使用容器作为构建源代码的工具链时。
例如：
podman build --platform linux/s390x -t myimage:mytag -f ./Dockerfile /tmp/mysrc
或者它可以是一个相对路径，比如：
podman build --platform linux/s390x -t myimage:mytag -f ./Dockerfile ../../
下面是使用全局路径的另一个例子:
FROM myImage:tag
...
...
COPY externalFile ./
ADD AnotherProject ./
...
注意现在Dockerfile命令层的
COPY和
ADD指令中完整的全局路径已被省略。在这种情况下，如果
externalFile和
AnotherProject都在
/opt目录下，则构建时
context dir必须相对于这些文件所在的位置。
podman build -t imageName:tag -f ./Dockerfile /opt
注意在使用 docker 中的上下文目录时使用 COPY 或 ADD:
docker 守护进程将尝试将可见的上下文目录树中的所有文件“流式传输”到守护进程，这可能会减缓构建速度。并需要用户从上下文目录递归授予权限。
当使用 API 进行构建时，这种行为可能更加昂贵。然而，
podman 可以即时构建，无需递归权限，因为它不枚举整个上下文目录，并且也没有使用客户端/服务器结构。
在面对使用不同上下文目录时遇到此类问题时，使用
podman 更加有趣且值得尝试。
podman 的相关构建可以参考以下链接：
https://docs.podman.io/en/latest/markdown/podman-build.1.html。如果想获得更多信息，可以查阅以下参考资料链接：
https://docs.docker.com/engine/reference/commandline/build/。
FROM从那里继续。我不打算改变项目结构来适应Docker（或任何构建工具）。 - Devis L.docker buildx build --build-context othersource= ../something/something .。请参见下面的答案。 - Sami Wood