Description

TL;DR -> Support a --no-pull option for compose up, to allow for build and image attributes to exist in a compose file, but also prioritize searching for the image locally and building + tagging it if it's not present, instead of pulling from a remote registry

More context and details

As of right now, docker compose up doesn't seem to support the possibility of NOT pulling an image from a remote registry if the build attribute is present in the compose file, ONLY searching for the image locally and building it if not present.

Some details on the use case I'm thinking about:

build and image keys are both present in a compose file;

I'd like to run a docker compose up command that would build an image using the build definition and tag it with the image tag, ONLY if an image with that tag is currently NOT PRESENT on the LOCAL container registry (on the machine itself).

The same way we have the --no-build option that can force skipping a build, I think a --no-pull option could also be quite nice to have.

Reading the compose specification, in particular under pull_policy, i see there is the following line: If pull_policy and build both presents, Compose implementations SHOULD build the image by default. Compose implementations MAY override this behavior in the toolchain.
This is currently unsupported, i've tried all pull_policy options

Aside from the spelling errors, I understand SHOULD is not MUST, but i still think it'd be good to support the use case of prioritizing a build over an image pull, without having to specify the --build option (as that would cause the rebuild of the image each time the compose command is run, or force the user to first determine if the containers exist locally by parsing the compose file for the image tag, and changing the compose command launched accordingly).

In my specific use-case, i use many compose files together as -f options, and would like to use a compose up command to handle both the local build of an image, and also the usage of a locally present image without having to rebuild the container each time. This would be the same behavior as NOT having an image attribute in the compose file.
A separate command would handle running the same services using images pulled from a remote-registry instead. Doing this with many compose services split up into various compose files (5-10+ potentially) becomes quite complex, especially without creating override compose files for each service.

Example

Imagine using the following compose file as the most basic example

services:
  A:
    build: ./serviceA
    image: remote.repo/service-A-image:latest
    ...
  B:
    build: ./serviceB
    image: remote.repo/service-B-image:latest
    depends_on: A
    ...

Proposed command option: docker compose up --no-pull

Idea of how that'd work:

• Check for remote.repo/service-A-image:latest locally.
• If present, use it.
• If not, build the image as defined by the build attribute and tag it with the image attribute's value
• Repeat above steps for service B

If I missed some part of compose that already allows this type of flow to be used, I'm sorry in advance 😛