Can't use --no-build with services with a build section

[z0w13]

When using docker compose up --no-build a check is done to ensure either image or build exists in a service:

compose/pkg/compose/build.go

Line 98 in 7365917

func (s *composeService) ensureImagesExists(ctx context.Context, project *types.Project, quietPull bool) error {

called from

compose/pkg/compose/create.go

Line 66 in ef786f9

err = s.ensureImagesExists(ctx, project, options.QuietPull)

However as the build section is removed in createOptions.Apply when --no-build is specified

compose/cmd/compose/create.go

Line 117 in 7c47673

if opts.noBuild {

This means that docker compose up --no-build always fails even if you've ensured these images have been built.

Full repro here: https://github.com/z0w13/docker-compose-no-build-repro

Output of docker compose version:

Docker Compose version 2.0.1

The behaviour in 1.x was (in my opinion) correct, failing if the image hasn't been preivously built and otherwise succeeding:

docker-compose up --no-build
ERROR: Service 'repro' needs to be built, but --no-build was passed.

docker-compose build
  Building repro
  [+] Building 0.0s (3/3) FINISHED
   => [internal] load build definition from Dockerfile
  0.0s => => transferring dockerfile: 31B
    0.0s => [internal] load .dockerignore
  0.0s => => transferring context: 2B
  0.0s => exporting to image
  0.0s => => writing image sha256:78f8bb0557f61538b4fbb173d0ca3a8f466d77cfeee0c62a1a6f969288eeff6b
  0.0s => => naming to docker.io/library/repro_repro
docker-compose up --no-build
  Creating repro_repro_1 ...

[debdutdeb]

Hi.

Doesn't seem like a bug to me, could be wrong.

First of all yours and my error messages are not the same. Mine says "invalid service "repro". Must specify either image or build" because I'm explicitely asking it to ignore any build instructions. Even if the image was build previously, how would compose know its id or name from literally nothing related?

To fix this just add an image section.

services:
repro:
image: dummy
build: "."

PS: my backtick key isn't working.

[thaJeztah]

To fix this just add an image section.

I don't think that should be needed; the image: section would be used to;

• if build: dummy is present: "pull the dummy:latest image (or use it from the local image cache if present)"
• if a build: section is present: "when building this service, build the Dockerfile, and name the image dummy:latest

If a service only has a build: section (but no image: section);

• when building the service (docker compose up, docker compose up --build or docker compose build);
  • build the Dockerfile, and (because no explicit name is set)
  • tag the built image as projectname_servicename:latest
  • start the service using the projectname_servicename:latest image
• when running docker compose up --no-build:
  • skip building the image (even if something has changed which would normally require it to be rebuilt)
  • start the service using the projectname_servicename:latest image (no image: name was specified, so use the default / generated name)

From the above, I think this is a bug; removing the build section looks like an "implementation detail"; instead it should "skip" the build, but still use the default generated image name (projectname_servicename:latest) as a default (as if the build was performed)

[debdutdeb]

Ah thanks Sabastiaan! Didn't know about that. Probably because I never not used an image key :p

[brantburnett]

FWIW, this is causing regressions for Visual Studio with docker-compose projects. These projects regularly perform up with --no-build. Applications that would work for local development before are now failing when Docker upgrades switch to using Compose v2.

The workaround is to add an image attribute to services that have build attributes only, but this shouldn't be required.