compose: Relative paths for -f are broken, and --project-directory appears to be stillborn

Our code-project is structure such that all the docker related stuff resides in a sub-folder ./docker including ./docker/docker-compose.yml and various files and folders (e.g. ./docker/nginx/nginx.conf) to be volume-mounted by docker-compose using relative paths. Our build job used to invoke docker-compose from the project root (e.g. /workspace/project) with the -f ./docker/docker-compose.yml option, which started to fail since the update to 1.12.0, complaining that it couldn’t find /workspace/project/nginx/ for mounting, which clearly should have been /workspace/project/docker/nginx/. I can change directory to /workspace/project/docker to avoid using the -f … option, to work around the problem. However, this clearly is a bug introduced in recent docker-compose, since nothing has changed in our project except the update to 1.12.0 (from 1.11.0, I guess).

ERROR: build path /workspace/project/nginx either does not exist, is not accessible, or is not a valid URL.

After some research I found, that 1.12.0 introduced the --project-directory option, so I tried docker-compose --project-directory ./docker from the project-root /workspace/project as before. It doesn’t appear to work either, complaining that it couldn’t find a suitable docker-compose.yml in this directory. Presumably, this directory mentioned is falsely assumed to be /workspace/project (=PWD), and docker-compose fails to properly check /workspace/project/docker as instructed (or maybe, I misunderstood the intended function of --project-directory …, in which case the -f … bug still applies).

ERROR: Can’t find a suitable configuration file in this directory or any parent. Are you in the right directory?
    Supported filenames: docker-compose.yml, docker-compose.yaml

Using absolute paths as in docker-compose -f /workspace/project/docker/docker-compose.yml or docker-compose --project-directory /workspace/project/docker won’t work either, except iff PWD=/workspace/project/docker, which renders -f and --project-directory completely useless.

I shall add that all mentioned paths are on the same file-system, and there are no soft-links involved.

For now, the only way to work around these problems is to cd /workspace/project/docker before every (parameterless) docker-compose invocation.

About this issue

Original URL
State: closed
Created 7 years ago
Reactions: 6
Comments: 17

Most upvoted comments

@dazhao-msft For Windows, you can download the Appveyor artifact here: https://ci.appveyor.com/project/docker/compose/build/master-3146/artifacts

shin- on Apr 7, 2017

I’m using Docker Toolkit for macOS, and I’m seeing this exact problem… but I’m on 17.06? and I’m up to date according to:

Docker 17.06.2-ce-mac27 is currently the newest version available.

$ docker-compose -v
docker-compose version 1.14.0, build c7bdf9e
$ docker -v
Docker version 17.06.2-ce, build cec0b72

What’s the status of this issue with macOS?

Cheers

dlgoodchild on Sep 13, 2017

@shin- Joffrey, do you know when the fix will be integrated in Docker CE for Windows? I checked the latest version 17.05.0-ce-rc1-win8 (11189), and the fix is not there yet.

This issue completely blocks the users from using Docker CE for Windows with Visual Studio. We hope to get this fix in ASAP.

Thanks! -David

dazhao-msft on Apr 17, 2017