compose: docker-compose terminates if build directory is missing

The best approach is to split files and provide docker-compose with multiple -f stanzas, for example maybe the bare necessities to run a service can remain in the docker-compose.yml file, but you can add in the build: part (the yaml structs will be merged) only during build operations by using e.g. docker-compose -f docker-compose.yml -f build.docker-compose.yml build for your project.

Taking this into account - terminating on missing build dir (which could potentially result in mis-built images, which would be more difficult to track downstream) could be considered a feature rather than a bug.

Version 1.24 problem still here!

v1.25.4 still no progress

I don’t think that your example is the situation that the original poster was reporting.

Impractical example:

$ cat docker-compose.yml
version: "3.2"
services:
  foo:
    build: src/foo
  bar:
    build: src/bar

$ docker-compose build foo
ERROR: build path src/bar either does not exist, is not accessible, or is not a valid URL.

$ why do you care?!
zsh: no matches found: care?!

If you are using docker-compose in 99% of cases to set up an environment with app1 and app2, then it is very nice to be able to specify that entire environment in one docker-compose file. I would be very unhappy if in my build setup I had to pass 5 -f stanzas every time I want to test something, in that case I would end up writing a layer of tooling around docker-compose, which is what I am trying to avoid. So for now, I’m also using the trick of just creating the build directories.

Note that the check for having a build directory is a strange one to do at this point, because there is absolutely no guarantee that you can build an image out of it. In particular, the check that there is a Dockerfile is done only when a build is requested.

$ mkdir src/bar
$ docker-compose build bar
ERROR: Cannot locate specified Dockerfile: Dockerfile
$ docker-compose build foo
Building foo
... why is it now safe to build foo, while it wasn't before?

I think what the original poster and the people who were chiming in before are asking, is that the check for the existence of the build directory is done at the same place as the check for the existence of a Dockerfile. This would be more consistent, and allows people to keep using docker-compose in the lightweight fashion they were used to.

I’m currently running into this issue with Jenkins deployment. I use the docker-compos build command to build the images locally, then push them to the registry. From there I go to the production server and want to dockere-compose rm -sf && docker-compose up copying over only the compose file and I get this error.

I’m getting around the issue by simply creating an empty directory. but it’s a rather clunky work around.

The build directory check happens when I run docker-compose down. Why do we need to check the build context before down the containers?

I’m running into this same issue.

I can confirm this issue is present in docker-compose version 1.23.2, build 1110ad0.

Docker compose is very useful for non-developers to quickly get an env up and running (eg. to demo) but this issue means you have to distribute a few files and not just a docker-compose.yml. It would be a very useful fix.