Description

I have a service that is defined in the docker-compose.yaml as well as in the docker-compose.override.yaml. The difference is basically that in the docker-compose.yaml I'm referencing the image property while in the docker-compose.override.yaml I have the build property to build the image based on a local Dockerfile. Also, the docker-compose.yaml contains a pull_policy: always property that is inherited in the docker-compose.override.yaml.

The problem is that the container does not start with the generated image from the Dockerfile if I have in the parent yaml (docker-compose.yaml) the pull_policy: always. It starts with the parent image defined. This is the configuration:

# docker-compose.yaml
services:
    myservice:
        image: an-image
        pull_policy: always

# docker-compose.override.yaml
services:
    myservice:
        build:
             dockerfile: docker/Dockerfile
             context: .

You can see a complete example with an nginx image here -> https://github.com/xserrat/docker-compose-pull-policy

Is that the expected behaviour?

No. I expected the use of the overridden image defined in the build.dockerfile property in the docker-compose.override.yaml file.

Steps to reproduce the issue:

1. Create a docker-compose.yaml like the following:

# docker-compose.yaml
services:
    myservice:
        image: an-image
        pull_policy: always

2. Create a docker-compose.override.yaml overriding the previous service by adding the build property to build a custom Dockerfile:

# docker-compose.override.yaml
services:
    myservice:
        build:
             dockerfile: docker/Dockerfile
             context: .

3. Execute docker compose up -d myservice.
4. You'll see that the image used in the container is the one defined in the docker-compose.yaml instead of using the image from the build.dockerfile property.
5. You can see a complete example here: https://github.com/xserrat/docker-compose-pull-policy

Describe the results you received:

I see that the image used to run the container is not the local one built using the Dockerfile.

Describe the results you expected:

I should see that the image used to run the container is the local one because the image property defined in the docker-compose.yml is overridden by the build property from the docker-compose.override.yml file.

Additional information you deem important (e.g. issue happens only occasionally):

Output of docker compose version:

Docker Compose version v2.6.1

Output of docker info:

Client:
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc., v0.8.2)
  compose: Docker Compose (Docker Inc., v2.6.1)
  extension: Manages Docker extensions (Docker Inc., v0.2.7)
  sbom: View the packaged-based Software Bill Of Materials (SBOM) for an image (Anchore Inc., 0.6.0)
  scan: Docker Scan (Docker Inc., v0.17.0)

Server:
 Containers: 42
  Running: 27
  Paused: 0
  Stopped: 15
 Images: 44
 Server Version: 20.10.17
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 10c12954828e7c7c9b6e0ea9b0c02b01407d3ae1
 runc version: v1.1.2-0-ga916309
 init version: de40ad0
 Security Options:
  seccomp
   Profile: default
  cgroupns
 Kernel Version: 5.10.104-linuxkit
 Operating System: Docker Desktop
 OSType: linux
 Architecture: aarch64
 CPUs: 4
 Total Memory: 8.721GiB
 Name: docker-desktop
 ID: AKFP:GZQE:Y6C5:R4RQ:RGWI:AQBD:U6BG:JGQV:AFUP:GEZP:5K6P:PI4C
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 HTTP Proxy: http.docker.internal:3128
 HTTPS Proxy: http.docker.internal:3128
 No Proxy: hubproxy.docker.internal
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  hubproxy.docker.internal:5000
  127.0.0.0/8
 Live Restore Enabled: false

Additional environment details:

I am using a Mac M1.