Avoiding build or image constraint

[koen-serry]

I was looking into the issue I just got regarding having both an image and a build inside my fig config, but I couldn't understand why this constraint exists.

Service .... has both an image and build path specified. A service can either be built to image or use an existing image, not both.

Because I may have both. If my image is not stale (ie. exactly the same as my Dockerfile) running from my image will be faster than rebuilding it. If however my image is stale (or I want to rebuild it just in case) I'd use fig build . I agree that now we save a step when you do a fig up, because it actually builds the image, but it's also a bit confusing. Would it be possible to have some kind of fallback so in case the image is not there it builds it?

[aanand]

When you specify a build directory, fig up checks for an image named <projectname>_<servicename>, and re-uses that if it exists - otherwise, it builds the directory and tags the image with that name. So we're already saving you the rebuild step.

[koen-serry]

I agree, but why put the contraint in the fig.yml and not use it instead as projectname_servicename

[dnephin]

The nice thing about projectname_servicename is that it makes all the image names consistent.

There has definitely been some discussion about this type of thing before (#541, #213, along with a couple PRs).

It seems like fig up already has the behaviour described, would it be fair to close this ticket and continue the discussion of tags/image_name in one of those tickets?

[chernjie]

compose/service.py#L184:L187:

        if (do_build and
                self.can_be_built() and
                not self.client.images(name=self.full_name)):
            self.build()

I too was hoping that this constraint is lifted. I have a private registry which causes the image name to be different from a build scenario, e.g. localhost:5000/my/image instead of my/image

It would be nice if docker compose first try the image and if not found then run build.

[dnephin]

Thanks for this proposal! let's continue the discussion in #2092