Closed
Description
Description
With COMPOSE_BAKE=true
being the new default now, I happened to spot our caches not being pushed anymore using our cache-to
fields setup in our compose.yaml
configuration files.
Unsure if there is something we are missing here or something has been misunderstood by me or whether something else needs to be configured on our hosts to enable the behaviour? We were using the buildkit
builder setup with the docker-container
driver.
We have changed the default for now back to false
but want to understand if this is intended and there is some sort of misuse on our end or a bug? Thank you, appreciate any help here! 👍🏼
Steps To Reproduce
- Create a test
compose.yaml
file with bare minimum configuration to reproduce this issue.
services:
my-app:
build:
cache_from:
- type=registry,ref=my-registry.com/my-app:main
cache_to:
- type=registry,ref=my-registry.com/my-app:main
- Run the
docker compose
command with--verbose
mode to show thebake
definition output:
docker compose --verbose -f compose.yaml build my-app
- Debug output will show what the
bake
definition generated, which is exactly what I'm seeing with no caches being pushed to the registry. This will only show thecache-from
fields generating:
TRAC[0000] Docker Desktop integration not enabled
DEBU[0000] bake build config:
{
"group": {
"default": {
"targets": [
"my-app"
]
}
},
"target": {
"auditmatic": {
"context": "/var/lib/home/tmp",
"dockerfile": "/var/lib/home/tmp/Dockerfile",
"tags": [
"my-app"
],
"cache-from": [
"type=registry,ref=my-registry.com/my-app:main"
],
"output": [
"type=docker,load=true,push=false"
]
}
}
}
- Use the raw
docker buildx --print
command to see how it generates outside of compose and is correct with the fields presented:
{
"group": {
"default": {
"targets": [
"my-app"
]
}
},
"target": {
"my-app": {
"context": ".",
"dockerfile": "Dockerfile",
"cache-from": [
{
"ref": "my-registry.com/my-app:main",
"type": "registry"
},
],
"cache-to": [
{
"mode": "max",
"ref": "my-registry.com/my-app:main",
"type": "registry"
}
],
}
}
}
Compose Version
v2.37.1
Docker Environment
Client: Docker Engine - Community
Version: 28.2.2
Context: default
Debug Mode: false
Plugins:
buildx: Docker Buildx (Docker Inc.)
Version: v0.23.0
Path: /usr/libexec/docker/cli-plugins/docker-buildx
compose: Docker Compose (Docker Inc.)
Version: v2.37.1
Path: /usr/libexec/docker/cli-plugins/docker-compose
Server:
Containers: 5
Running: 5
Paused: 0
Stopped: 0
Images: 5
Server Version: 28.2.2
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Using metacopy: false
Native Overlay Diff: true
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:
apparmor
seccomp
Profile: builtin
userns
cgroupns
Kernel Version: 6.11.0-1015-gcp
Operating System: Ubuntu 24.04.2 LTS
OSType: linux
Architecture: x86_64
CPUs: 8
Total Memory: 31.34GiB
Name: ferocia-builder-3004
ID: 3f43c53f-e2ed-4e3c-b5a2-3924b66da522
Docker Root Dir: /var/lib/docker/2000.2000
Debug Mode: false
Experimental: true
Insecure Registries:
::1/128
127.0.0.0/8
Live Restore Enabled: false
Default Address Pools:
Base: 172.17.0.0/20, Size: 26
Base: 172.17.16.0/20, Size: 26
Base: 172.17.32.0/20, Size: 26
Anything else?
No response