Document that fig does not always rebuild images automatically

[jamshid]

Fig does not seem to rebuild the image it uses to create a container when the referenced "build:" Dockerfile or directory has changed. More documentation about how using "build:" differs from "docker build" would be good.

E.g., I have directories "foo" and "foo-single":

foo/Dockerfile

...

foo-single/Dockerfile

FROM foo
...

I changed foo/Dockerfile and rebuilt both images with "docker build -t foo ./foo" and "docker build -t foo-single ./foo-single" (though I guess that doesn't matter, fig only looks at the build directory?).

My fig.yml has this so I expected it to pick up the new foo-single, but it does not. I even tried deleting the container ("docker rm myproject_bar") thinking it would check for build changes, but it still used the outdated "myproject_bar" image .

bar:
  build: foo-single

I guess fig doesn't check if the Dockerfile or its directory contents have changed? I had to explicitly "docker rmi myproject_bar" in order to get the new "foo" changes.

[aanand]

fig build will rebuild the image.

Auto-build is analogous to auto-pull (whose behaviour in turn mirrors docker run IMAGE) - if the image exists, it doesn't do anything.

[thaJeztah]

@aanand I think the message shown when running fig up is confusing; (re)building .... when, in fact, it doesn't re-build the images?

[jamshid]

Ah ok, thanks for the explanation. Yes the "(re)building" message is a bit confusing.
I guess this makes sense, you are trying to avoid auto-rebuilding images since it can take a long time. Maybe more docs around this, otherwise this can be closed.
Hmm I might change back to building images by their directory name and use "image: foo..." in my fig.yml instead of "build: foo...". Or I could just remember to do an explicit "fig build" when I've made Dockerfile changes.

[kevana]

+1 @aanand It wasn't clear to me that fig build rebuilds images.

[udl]

+1 I also had expected, that fig automatically rebuilds when my code changes ... maybe an auto-build switch in fig.yml could be a solution?

[aaronshaf]

This bit me today. +1

[83tb]

Same here, took me half an hour today to figure out that the image is not being rebuilt when I make changes to Dockerfile. I think default docker behaviour is rebuilding from the first changed line in a file so I was expecting this.

[aanand]

@83tb that's not "default docker behaviour", it's what Docker does if you run docker build, as well as what Fig does if you run fig build. Docker will never automatically build your image for you.

It's clear that Fig's behaviour is confusing a lot of new users. I can see two obvious ways to alleviate this:

• by default, build on every invocation of fig up (fig up should build on every invocation #12)
• by default, don't build on fig up (Proposal: don't "build" as part of "docker-compose up" #693)

[83tb]

I meant default for docker build not docker run, my mistake

I would vote for #2.

[jamshid]

I think I lean towards option 2, forcing people to make build an explicit part of their workflow (#693).

[lorinbeer]

+1
bit by this today

documentation for 'fig up' also compounds the issue http://www.fig.sh/cli.html
documents that it "(re)creates ... containers", but that does not imply a rebuild of the image the container is dependent on.

While technically correct, this was confusing.

[hadim]

I would vote for options 2 also.

[bitliner]

+1 for option 1, to rebuild image at each fig up.

Furthermore, I was wondering: why don't you change the flow, such that it is: build → stop → start at each fig up? If you run build after stop then you have downtime that is not nice to have.

Anyway to avoid all these changes, it is enough to run fig build just before fig up

[cancan101]

👍 rebuild image on each up.

[develar]

Correct dockerfile doesn't lead to slow rebuild. Even on my old slow MacBook Air it tooks less than a second. Otherwise I have to use "docker-compose build && docker-compose up" to not worry about it on each change. So, +1 "rebuild image on each up.".

[pospispa]

My opinion:

• up does not rebuild if it's available locally
• if I want explicit rebuild I must call it explicitly:
  docker-compose build
  docker-compose up

[udl]

Would a parameter make sense?
docker-compose up --rebuild or something like that?

[develar]

@udl No. Imagine:

1. You push changes.
2. Your colleague pull the changes.
3. "docker-compose is so cool — you need just "run docker-compose up and Compose will start and run your entire app."" But... wait... oh, ***, I need to prepend "docker-compose build &&".

So, in the end, the question — what is the purpose of this command, if it cannot "start and run your entire app" and need in any case use another command (or option) in addition?

I think, "up" in any case is not "incremental" command — to speedup (if need) development, I will use restart/reload commands (docker-compose doesn't support completely this workflow yet, but it is another topic).

[udl]

@develar I personally would prefer re-building on every docker-compose up as well. Just thought, a CLI parameter would be a compromise for those, that don't want to have it.

I think the confusion about how up works comes from the fact, that it automatically builds when the image is not available (which is great). But from that behaviour, one expects that it always automatically checks, that the image is up to date.

[RoeyPrat]

Sorry if this is naive, but is it possible to automatically rebuild if *.yml or Dockerfile were updated since last build?
It seems to me if the user updates said files they would like to rebuild, without stating so explicitly.

[ghost]

thought this woul be the default behaviour of compose 👍

[lwcolton]

This is technically fixed, https://docs.docker.com/compose/reference/up/ However, I think the language used is very confusing. Instead of talking about "picking up changes", it might be better to just say "By default, if a service's image and configuration have not changed, that service's containers will not be re-created." Can a core contributor either close this issue or +1 my suggestion and I will PR?

[dnephin]

In #2601 we added a warning any time up actually builds an image to inform you that this is a one-time thing. This should prevent confusion in the future.

We also add the --build flag.

[dnephin]

We're always interested in PRs which improve the docs, so please don't hesitate to submit a PR to improve them. Thanks!