Open Evesy opened 1 year ago
What your bake definition looks like? Are you exporting cache?
Sorry for not replying, must have missed the response. The bake definition is using docker-compose.yml
which looks like the below:
version: "3.8"
services:
app:
image: "eu.gcr.io/at-artefacts/at-monkeynetes"
network_mode: bridge
build:
context: .
args:
GO_DEPENDENCY_LABEL_BASE_JAVA_17: "${GO_DEPENDENCY_LABEL_BASE_JAVA_17:-latest}"
ports:
- "8080:8080"
- "9090:9090"
environment:
ENABLE_GC_LOGS: "true"
JVM_MAX_HEAP_MB: 200
ENABLE_JFR: "true"
mem_limit: 512m
I had observed it using no cache export, and also when using inline cache export. I can't say I've ran into the issue recently so perhaps it was inadvertently fixed in an upgrade somewhere along the way. Given no one else seems to have observed the same I'd be happy for this to be closed off unless you want to keep it open?
Contributing guidelines
I've found a bug and checked that ...
Description
Occasionally seeing
docker buildx
builds failing with the below:After encountering this, all subsequent build attempts fail the same. Only on a Docker restart will things begin working again.
Expected behaviour
Actual behaviour
This happens intermittently, and I have yet to get an exact reproducible example. Below is chain of events that led to being able to reproduce the issue last time:
The above command had ran & built successfully. Subsequent builds were also cached and completed very quickly.
I then pruned docker, and the buildx builders:
I reran the exact same command as before, but it failed with the below:
Interesting to note, is the build above was started at
10:41:44
. The token being used in the above failed request was one that was returned by the credential helper foreu.gcr.io
, at10:25:03
(Even though I can see the cred helper being called and returning a different token at10:41:46
after the build was startedSo it seems somewhere Docker is caching layers with access tokens that may have since expired (since our access tokens only have between 5-60 minutes TTL).
This then affects any Docker builds using that same
FROM
image:Worth noting it's not always on the
FROM
stage that it fails, another example failed during aCOPY
directive:Buildx version
github.com/docker/buildx v0.10.5 86bdced7766639d56baa4c7c449a4f6468490f87
Docker info
Builders list
Configuration
Build logs
Additional info
I think we've only observed this for multiarch builds, however that could also just be down to the fact those builds generally take a lot longer than singlearch builds