devthefuture-org
Nesting several Dockerfiles using Relative FROM breaks relative paths
Hi!
Thank you for this project. I have problems when I try to separate my build to several stages using Relative FROM. It seems like that this feature cause relative path corruption when there are more than one Relative FROM in dockerfiles chain
How to reproduce
Project structure:
├── dockerfiles
│ ├── Dockerfile.stage1
│ ├── Dockerfile.stage2
│ └── Dockerfile.stage3
├── file1.txt
├── file2.txt
└── file3.txt
Dockerfile.stage1:
FROM alpine
COPY file1.txt ./
Dockerfile.stage2:
#syntax = devthefuture/dockerfile-x
FROM ./dockerfiles/Dockerfile.stage1
COPY file2.txt ./
Dockerfile.stage3:
#syntax = devthefuture/dockerfile-x
FROM ./dockerfiles/Dockerfile.stage2
COPY file3.txt ./
Execute:
When I run stage1 and stage2 builds it works fine:
docker build -f dockerfiles/Dockerfile.stage1 .
docker build -f dockerfiles/Dockerfile.stage2 .
But stage3 build exits with error:
docker build -f dockerfiles/Dockerfile.stage3 .
Output:
[+] Building 1.8s (8/8) FINISHED docker:default
=> [internal] load build definition from Dockerfile.stage3 0.0s
=> => transferring dockerfile: 137B 0.0s
=> resolve image config for docker.io/devthefuture/dockerfile-x:latest 1.3s
=> [auth] devthefuture/dockerfile-x:pull token for registry-1.docker.io 0.0s
=> CACHED docker-image://docker.io/devthefuture/dockerfile-x:latest@sha256:2fbc2fe8ae7f7e29d6c419b92775ca0596a866de86a8c74f3c652b77f893ce6e 0.0s
=> local://dockerfile (Dockerfile.stage3) 0.0s
=> => transferring dockerfile: 38B 0.0s
=> local://context (dockerfiles/Dockerfile.stage2) 0.0s
=> => transferring context: 184B 0.0s
=> local://context (dockerfiles/dockerfiles/Dockerfile.stage1) 0.0s
=> => transferring context: 2B 0.0s
=> local://context (dockerfiles/dockerfiles/Dockerfile.stage1.dockerfile) 0.0s
=> => transferring context: 2B 0.0s
Dockerfile.stage3:1
--------------------
1 | >>> #syntax = devthefuture/dockerfile-x
2 |
3 | FROM ./dockerfiles/Dockerfile.stage2
--------------------
ERROR: failed to solve: failed to execute dockerfile-x: failed to read dockerfile 'dockerfiles/dockerfiles/Dockerfile.stage1.dockerfile': open dockerfiles/dockerfiles/Dockerfile.stage1.dockerfile: no such file or directory
, Output:
Problem
Seems like first Relative FROM in chain change cwd for next Relative FROMs
Expected behaviour:
Relative FROM always works relative to build context
This is an expected behavior, the relative path is relative to the dockerfile itself. Only the root dockerfile is relative to the build context. From the documentation:
The paths resolutions for imported Dockerfiles from the root Dockerfile are relative to the docker build context, not the root Dockerfile itself. This is due to a limitation in BuildKit and this is consistent with other instructions that are also relative the context.
However, the paths resolutions for imported Dockerfiles from the imported Dockerfiles are relative to the imported Dockerfile itself.
If you really need to use the build context in the include path, we could think as a kind of variable or something like FROM $BUILD_CONTEXT/dockerfiles/Dockerfile.stage2
@devthejo wouldn't it ease the project usage if all relative FROM/INCLUDE paths were always from the context folder?
Thanks a lot for this!!
@devthejo wouldn't it ease the project usage if all relative FROM/INCLUDE paths were always from the context folder?
I think it would be more intuitive if all relative FROM/INCLUDE paths were resolved from the calling file, but limitations on buildkit doesn't not allow this for the entry point Dockerfile. In my experience, on monorepo that heavily rely on it, it's making more sense to have the actual behavior. Each package can have it's own Dockerfile using shared Dockerfile(s) from a dockerfile-x dedicated folder that contain inter-dependents dockerfiles, and theses inter-dependents dockerfiles can call each other relatively. So it can be like having a package of dockerfiles, that are agnostics from the project/context. I agree that the explanation would be more easy, but in my opinion, the usage will be less. But we could add an option to allow this behavior if in some usage cases it make more sense.