Failing to read file in 4.21.1 #6912
Assignees
Comments
|
Can you provide a slightly more complete repro example?
services:
service-a:
build:
context: serviceA
service-b:
build:
context: .
dockerfile: ./serviceB/Dockerfile
FROM nginx❯ docker compose up --wait --build
[+] Building 0.1s (8/8) FINISHED
=> [service-a internal] load build definition from Dockerfile 0.0s
=> => transferring dockerfile: 85B 0.0s
=> [service-a internal] load .dockerignore 0.0s
=> => transferring context: 2B 0.0s
=> [service-b internal] load metadata for docker.io/library/nginx:latest 0.0s
=> CACHED [service-b 1/1] FROM docker.io/library/nginx 0.0s
=> [service-a] exporting to image 0.0s
=> => exporting layers 0.0s
=> => writing image sha256:b3e55f3faec3c2f56d1fde218969e0696bddb20c44cb3d9a883a430f1f4755af 0.0s
=> => naming to docker.io/library/formac6912-service-a 0.0s
=> [service-b internal] load build definition from Dockerfile 0.0s
=> => transferring dockerfile: 85B 0.0s
=> [service-b internal] load .dockerignore 0.0s
=> => transferring context: 2B 0.0s
=> [service-b] exporting to image 0.0s
=> => exporting layers 0.0s
=> => writing image sha256:5af17e2fbbdbaff3565107c3b1e0545f243ac9233d5501fecd324115ebe291e5 0.0s
=> => naming to docker.io/library/formac6912-service-b 0.0s
[+] Running 3/3
✔ Network formac6912_default Created 0.0s
✔ Container formac6912-service-a-1 Healthy 0.9s
✔ Container formac6912-service-b-1 Healthy 0.9s |
|
Sure, let me know if this helps. full-stack/docker-compose.yaml: full-stack/serviceA/docker-compose.yaml: full-stack/serviceA/Dockerfile: Service B is defined similarly |
|
Thank you, I pinpointed the issue and we will get a fix into Compose. The key here is around the lack of services:
image: serviceA:latest
build:
target: development
+ context: .
volumes:
- .:/usr/src/app
- serviceA_nodeModules:/usr/src/app/node_modulesThat will properly resolve the build context to |
|
@milas thanks for the workaround! I will try it out tomorrow and let you know if that resolves the issue. |
milas
added a commit
to milas/compose-go
that referenced
this issue
Jul 13, 2023
When using `extends.file` to load a service from another Compose file, if the `build.context` field wasn't explicitly set, it would get ignored by the path resolution. As a result, the build context would end up as the working directory of the _root_ Compose file instead of the working directory of the _loaded_ Compose file. This was because the relative path resolution logic ignored empty `build.context` values. Unfortunately, removing that restriction is itself not sufficient, as it then attempted to verify that the local path existed in an attempt to avoid unintentionally joining the working directory with a remote context value (e.g. `/foo/https://github.com/my/repo.git`). This is problematic because the working directory itself might be relative (rooted to an unknown location that is != `.`), so it will be resolved relative to the current process working directory, and thus fail the existence check. In practice, this happens when using `extends.file`, where we do resolve paths but intentionally pass a potentially relative value for the working dir, thus making it unsafe to be doing real filesystem operations here. In fact, even if a context was specified, it was possible to break this by running Compose from a different directory than the _root_ Compose file while specifying the path to it. As there's no formal specification for determining local path vs. remote build contexts (see discussion in compose-spec#385), I'm simply eliminating the existence check. This COULD mean that Compose begins to erroneously consider remote context values as local paths if builders add new unsupported syntaxes, but I think it's fair for us to be more restrictive. Additionally, I've ensured that when path resolution is happening, it _always_ resolves the `build.context` to an absolute path for consistency. In particular, this should help make it easier to use the output of `docker compose config` from arbitrary working directories. There's a new test that covers the `extends.file` + `build.context` behavior, and everal existing test adjustments to account for the fact that Compose was emitting relative `build.context` paths from `docker compose config` despite everything else being absolute (such as volumes). Fixes docker/for-mac#6912. Signed-off-by: Milas Bowman <milas.bowman@docker.com>
|
This specific scenario is not well covered (actually, not covered at all) by the specs and documentation. We could debate context defaults to so, basically, to support this use-case, you better should use an explicit |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description
We are running a multi-container application, and after updating to Docker desktop for silicon Mac I was getting the following error trying to build and run many of our service containers:
Reproduce
Create a multi - container application with this structure
full-stack
|- - docker-compose.yaml
| - - serviceA
| - - - - docker-compose.yaml
| - - - - Dockerfile
| - - serviceB
etc.
And try to run docker compose up --build serviceA from the full-stack directory. The following error will be encountered:
Expected behavior
The container should build and run
docker version
docker info
Diagnostics ID
Can't regenerate without going to broken version again
Additional Info
Rolling back to 4.20.1 fixed the issue. I can't replicate the error in 4.20.1, so I am unable to provide some of the information requested above. 4.21.1 is the version that has the issue.
The text was updated successfully, but these errors were encountered: