-
Notifications
You must be signed in to change notification settings - Fork 5.5k
Description
Description
Using pull: true
in the build
section for a service is not working for me. This was broken somewhere between 2.36.2
and 2.37.3
(these were just the 2 versions closest to each other I could install via apt). I tested with docker compose build
and docker compose run --build service-name
and both failed. Specifically I am checking
I think the issue at play is actually a deeper caching issue where compose is not pulling images that exist in docker image ps
(more in the repro steps)
Steps To Reproduce
Use the following Dockerfile
and docker-compose.yml
# Dockerfile
FROM node:22
RUN echo "hello"
# docker-compose.yml
services:
test:
build:
context: .
dockerfile: Dockerfile
pull: true
- Run
docker image pull node:22
- Run
docker compose build
. According to the docs, this should pull the latest forFROM
every time because ofpull: true
- The first time, the output will show something like
[1/2] FROM docker.io/library/node:22@sha256:37ff334612f77d8f999c10af8797727b731629c26f2e83caa6af390998bdc49c
- Run
docker compose build
again. The expected output (and output on 2.36) is the same as above (possibly withCACHED
). Instead, the SHA is omitted and it just prings[1/2] FROM docker.io/library/node:22
- Run
docker image delete node:22
- Run
docker compose build
2 more times. Both times will print the SHA.
This can also be verified by pushing an image with a tag to a remote repository, pulling that image, then pushing a new version with the same tag that does something different. In my case, I had an image which runs a server that I had previously docker run ...
or started via other compose files on its own. In my compose file which builds a Dockerfile
that builds on top of that image, I was seeing the base image stay stale because my docker image ls
showed the latest
tag was last pulled months ago and the pull: true
was not actually updating the image, just building on top of the stale image.
Compose Version
Docker Compose version v2.37.3
docker-compose not found
Docker Environment
Client: Docker Engine - Community
Version: 28.3.3
Context: default
Debug Mode: false
Plugins:
buildx: Docker Buildx (Docker Inc.)
Version: v0.26.1
Path: /usr/libexec/docker/cli-plugins/docker-buildx
compose: Docker Compose (Docker Inc.)
Version: v2.37.3
Path: /usr/libexec/docker/cli-plugins/docker-compose
scan: Docker Scan (Docker Inc.)
Version: v0.23.0
Path: /usr/libexec/docker/cli-plugins/docker-scan
Server:
Containers: 23
Running: 0
Paused: 0
Stopped: 23
Images: 255
Server Version: 28.3.3
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Using metacopy: true
Native Overlay Diff: false
userxattr: false
Logging Driver: json-file
Cgroup Driver: systemd
Cgroup Version: 2
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
CDI spec directories:
/etc/cdi
/var/run/cdi
Swarm: inactive
Runtimes: io.containerd.runc.v2 runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 05044ec0a9a75232cad458027ca83437aae3f4da
runc version: v1.2.5-0-g59923ef
init version: de40ad0
Security Options:
seccomp
Profile: builtin
cgroupns
Kernel Version: 6.15.4-x64v3-xanmod1
Operating System: Pop!_OS 22.04 LTS
OSType: linux
Architecture: x86_64
CPUs: 16
Total Memory: 78.46GiB
Name: pop-os
ID: caea0d55-0f17-41b5-be28-ea2567eed8b9
Docker Root Dir: /var/lib/docker
Debug Mode: false
Experimental: false
Insecure Registries:
::1/128
127.0.0.0/8
Live Restore Enabled: false
Anything else?
2.36.2 works. 2.37.3 does not. Tried multiple versions of Docker between 23 and 28 and compose seemed to be the culprit