Proposal: don't "build" as part of "docker-compose up"

[dnephin]

I've started to feel that doing a build during docker-compose up is potentially causing more trouble than it's worth, and I'm curious if anyone is actually using this functionality.

I believe this is a positive change for two reasons:

1. Anytime I've used docker-compose up I've always had to explicitly docker-compose build first (and often docker-compose pull before that). This is because without doing an explicit build/pull, you risk running an older version of the image.
2. Doing a build/pull as part of up starts to require that up support every parameter that build and pull require, which leads to more code complexity, and a less clean interface (see no cache #687, fig up support '--allow-insecure-ssl' #573, Speed up fig up #586, which are probably just the start)

Does anyone actually "need" docker-compose up to build containers first? How do you ensure you're actually running the latest container if you don't do an explicit docker-compose build first?

This would be a non-backwards compatible change, so it would require waiting for a new major release.

[dnephin]

Another option would be to default to no build/pull, but add a flag to enable a forced build/pull (even if the containers and images exist), and remove and build/pull flags from fig up.

[bfirsh]

Could we make it an option in a file?

[nathanleclaire]

Generally I'm in favor of pulling the build/pull step out and making it more explicit. I ran into a case last week where someone wasted days trying to debug a fig issue because they didn't understand that fig up wouldn't build the image like it did the first time (and they didn't have the files mounted in a volume etc.).

[md5]

@nathanleclaire I believe that problem may have been the root cause of an issue I had a user report last week: postgis/docker-postgis#5 (comment)

[iMerica]

+1

I'm not sure if this proposal is still on the table, but I agree fig up building by default is one command doing too much. It forces the essential operation of running a container + port mapping + mounting volumes into assumptions that everyone will want to build first.

As a user, I would prefer commands to be more composable (no pun intended).

[gillesdemey]

I can attest to the fact that it took me a while to figure out that fig up does not build the image the way that it does the first time around.

So I'm in favor of making it more explicit, and less like magic.

[funkyfuture]

i propose this syntax:

$ docker-compose up --update [<services>]

and:

service:
  force_update: true

the design should be coherent with the forced pull when building an image as proposed in #726

[ghost]

👍 to @funkyfuture 's idea of an --update option + a default of never building for docker-compose up.

[ollyjshaw]

+1. Principle of least surprise. It certainly surprised me that it didn't build if there had been change.

[nhooey]

+1 to @funkyfuture's idea.

docker-compose up and docker-compose run should either build and rebuild all of the time, or never build and rebuild, instead of building sometimes which misleads the user.

A --update (which could also be called --rebuild) lets the user force the opposite behaviour.

[dnephin]

Yes, we're planning on doing one of these for 1.6, and providing either a --build or --no-build (already exists) depending on which one gets implemented.

It's likely we'll be going with #12 and using the existing --no-build

[montanaflynn]

I just ran into this issue as well, only by docker exec -it container bash and checking the file manually was I able to tell that the changes were not taking place. I think a flag would be an improvement but having a rebuild directive in the docker-compose.yaml would be welcomed. It could behave similarly to the restart directive.