[BUG] `pull_policy: build` lacks equivalent to `--quiet-pull`

[polarathene]

Description

TL;DR:

• Please support --quiet-build equivalent to --quiet-pull if pull_policy: build is behaving as intended.
• Consider deriving an image name fallback from build.tags when present, instead of only concatenating project + service names.

---

Similar to this issue which appears to have been resolved with docker compose run --quiet-pull, it would be nice if there was an equivalent for services that build locally instead of pull.

Doc reference:

• https://docs.docker.com/reference/compose-file/build/#using-build-and-image
• https://docs.docker.com/reference/compose-file/build/#tags
• https://docs.docker.com/reference/compose-file/services/#image
• https://docs.docker.com/reference/compose-file/services/#pull_policy

If the service has no image field, it'll derive one for the image name to be built from the compose project + service names. Build tags are always append, so if you did not want the implicit image name, you would need to provide an explicit one via image.

Doing so will have the pull_policy by default try to pull that remotely if there is no existing image. If there is an existing image, then there is no redundant output.

Steps To Reproduce

name: my-project
services:
  my-service-a:
    build:
      dockerfile_inline: |
        FROM alpine

  my-service-b:
    image: localhost/my-service-b
    build:
      dockerfile_inline: |
        FROM alpine

  my-service-c:
    image: localhost/my-service-c
    pull_policy: build
    build:
      dockerfile_inline: |
        FROM alpine

• my-service-a builds the image as my-project-my-service-a
• my-service-b has a once off warning that the pull failed if the name doesn't resolve remotely:

  ! my-service-b Warning Get "http://localhost/v2/": dial tcp [::1]:80: connect: connection refused
  

However for my-service-c where a local build is enforced via pull_policy: build, but the image is tagged with a customized name (grouping under localhost/ for example), this always results in noise for building the image even when there is no context change:

# Could also be: docker compose run --rm my-service-c
$ docker compose up my-service-c

[+] Building 0.2s (6/6) FINISHED                                                                          docker:default
 => [my-service-c internal] load build definition from Dockerfile                                                   0.0s
 => => transferring dockerfile: 116B                                                                                0.0s
 => [my-service-c internal] load metadata for docker.io/library/alpine:latest                                       0.0s
 => [my-service-c internal] load .dockerignore                                                                      0.0s
 => => transferring context: 2B                                                                                     0.0s
 => CACHED [my-service-c 1/1] FROM docker.io/library/alpine:latest                                                  0.0s
 => [my-service-c] exporting to image                                                                               0.0s
 => => exporting layers                                                                                             0.0s
 => => writing image sha256:b37192f1609b544629b31b920b5ed3925fa283ffe1af7f714e4a874a5362493f                        0.0s
 => => naming to localhost/my-service-c                                                                             0.0s
 => [my-service-c] resolving provenance for metadata file                                                           0.0s

That seems redundant? It either should not be output, or some option akin to --quiet-pull should be supported to omit that noise.

Meanwhile:

• my-service-b config is valid to use if you're sure the image name chosen won't resolve remotely.
• The derived image name for my-service-a is not really desirable. I'm not sure how likely it is someone would depend upon that and explicit build.tags, so if build.tags were specified perhaps the fallback image name could prefer build.tags[0] (first tag), and thus pull_policy: build would not be necessary while also avoiding the noise output demonstrated via my-service-c.

Compose Version

Docker Compose version 2.30.3

I checked release notes since this version and nothing suggests the output/behaviour would differ.

Docker Environment

Client:
 Version:    27.3.1
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  0.18.0
    Path:     /usr/libexec/docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  2.30.3
    Path:     /usr/libexec/docker/cli-plugins/docker-compose

# Omitted some lines:
Server:
 Server Version: 27.3.1
 Storage Driver: overlay2
 Cgroup Driver: systemd
 Cgroup Version: 2
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: /usr/bin/tini-static
 containerd version: 3.fc41
 runc version:
 init version:
 Kernel Version: 6.11.7-300.fc41.x86_64
 Operating System: Fedora Linux 41 (Server Edition)
 OSType: linux
 Architecture: x86_64
 Insecure Registries:
  127.0.0.0/8

Anything else?

No response

[JosephGladwinGeorge]

Hi @ndeloof @polarathene I would like to take on the --quiet-build implementation.
I've implemented --quiet-build for run under branch 12462 in my repo.

with behaviour:
$ go run . -f ../../docker-compose.yml run --quiet-build my-service-c
/ # exit

without --quiet-build:
go run . -f ../../docker-compose.yml run my-service-c
[+] Building 1.4s (6/6) FINISHED docker:desktop-linux
=> [my-service-c internal] load build definition from Dockerfile 0.0s
=> => transferring dockerfile: 49B 0.0s
=> [my-service-c internal] load metadata for docker.io/library/alpine:latest 1.2s
=> [my-service-c internal] load .dockerignore 0.0s
=> => transferring context: 2B 0.0s
=> CACHED [my-service-c 1/1] FROM docker.io/library/alpine:latest@sha256:56fa17d2a7e7f168a043a2712e63aed1f8543aeafdcee47c58dcffe38ed51099 0.0s
=> [my-service-c] exporting to image 0.0s
=> => exporting layers 0.0s
=> => writing image sha256:512d1e44d6d1d55feb09d19a78136fc77a1566abb55f6973281c26d5aab96cfb 0.0s
=> => naming to localhost/my-service-c 0.0s
=> [my-service-c] resolving provenance for metadata file 0.0s
/ # exit

Can you please check it out and guide me as this is my first opensource contribution.