-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cache manifest lists can't be exported to gcr #1143
Comments
I haven't worked on the project in a while, but, I can tell you that GCR is very strict with what it will accept in a few places... especially here. The You might have better luck if you set the mediaType to an image index, which specifies annotations, but I'm guessing that will also break because the descriptors reference mediaTypes we don't recognize ( The guidance to ignore unrecognized mediaTypes was added relatively recently (well after I added image index support to GCR). I'm pretty sure we only expect an image index to reference an OCI manifest:
I'm pretty sure we'll fail for nested indexes as well, even though we SHOULD support it:
cc @yolo3301 |
The error changed when switching to oci types(can't do this by default as would limit the number of supported registries).
fyi, similar manifest lists are also used in containerd checkpoints https://github.com/containerd/containerd/blob/c6da899e2fd5ec5f0863d4be5ff683ee785d155c/images/mediatypes.go#L34 |
Do most registries work with this? |
oci support was added in version 2.7 to reference registry https://github.com/docker/distribution/releases/tag/v2.7.0 . There is also limited support among runtimes for oci mediatypes support so not only registry side issue. For buildkit side, we can allow oci mediatypes in cache export if user requests but as shown in #1143 (comment) it doesn't help with that case. |
I meant do most registries allow this: {
"schemaVersion": 2,
"mediaType": "application/vnd.docker.distribution.manifest.list.v2+json",
"manifests": [
{
"mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
"digest": "sha256:0503825856099e6adb39c8297af09547f69684b7016b7f3680ed801aa310baaa",
"size": 2789742,
"annotations": {
"buildkit/createdat": "2019-08-14T17:52:26.789506223-07:00",
"containerd.io/uncompressed": "sha256:1bfeebd65323b8ddf5bd6a51cc7097b72788bc982e9ab3280d53d3c613adffa7"
}
},
{
"mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
"digest": "sha256:a8ce4bba72fb43cbaeb05eca5d6d682696b915c53a3519d0f00f5aec063c0ae9",
"size": 219,
"annotations": {
"buildkit/createdat": "2019-08-19T14:39:20.018002388-07:00",
"containerd.io/uncompressed": "sha256:72e39bafb519d4c8b9d12597a538667085627a6b8c3c3f085d319d3ef6955b4f"
}
},
{
"mediaType": "application/vnd.buildkit.cacheconfig.v0",
"digest": "sha256:02656190e9941165d11c1ac96d683c3da0cec10714e01ed4de4b6ded7e8b7c49",
"size": 565
}
]
} as a manifest? I'd be really surprised. |
Depends on what you mean by most. Every registry based on https://github.com/docker/distribution allows it without any updates. Docker hub didn't require any updates. I know Azure Container Registry works fine as well. ECR otoh still doesn't support any variant of manifest lists afaik. The same pattern is used for example in containerd checkpoints definition and cnab-oci (that is used by docker app for example). |
It just seems to me that anyone implementing manifest list support based on reading https://docs.docker.com/registry/spec/manifest-v2-2/#manifest-list would probably reject that manifest. |
I get almost the same thing but a 401 error, so maybe slightly different. Uncahced:
cached:
|
ECR now has support for manifest-lists (aws/containers-roadmap#505), but is probably also bouncing off this issue and rejecting buildkit cache manifest-lists. |
Any update on this? I can't
|
Let's say theoretically I wanted to fix this :) How can I reliably reproduce this failure? |
For reproducing the 400 when exporting the manifest: Prerequisites:
There are a few mentions of 401 and 403 responses—at a glance those seem like actual permission issues. Cache export encounters error:
You should see a
For what it's worth, I've also tried exporting cache (max) to Google Cloud Artifact Registry (beta) with no success. |
Looks related to docker/build-push-action#171. Can you use the following command to create a new builder and try again?:
|
gcr.io: not working, probably won't
pkg.dev: workingℹ️ Requires format: `{projectid}/{docker_repository}/{image_repository}
@crazy-max similar to this comment about the missing third path segment, that fixed it for me as well on |
AFAIK Google suggests to switch to GAR:
cc. @jonjohnsonjr |
If you get |
Thanks!
This is really frustrating, because we return a structured error describing exactly the issue, but containerd swallows it: docker/build-push-action#171 (comment)
Hang tight.
This changed recently! https://cloud.google.com/blog/products/devops-sre/artifact-registry-is-ga |
GitHub Container Registry doesn't work either, see #1865. |
Am I reading this correct that cache export does not work with GAR? |
@gajus I can confirm cache export does work with Google Artifact Registry. |
Perhaps I am misunderstanding something, but even though I have it configured as such: buildctl-daemonless.sh build \
--frontend=dockerfile.v0 \
--local context=. \
--local dockerfile=$CI_PROJECT_DIR \
--opt build-arg:CWA_API_URL="$CWA_API_URL" \
--opt build-arg:SENTRY_AUTH_TOKEN="$SENTRY_AUTH_TOKEN" \
--opt build-arg:SENTRY_ORG="$SENTRY_ORG" \
--opt build-arg:SENTRY_PROJECT="$SENTRY_PROJECT" \
--opt build-arg:SENTRY_RELEASE="$CI_COMMIT_SHORT_SHA" \
--export-cache type=registry,ref=$GAR_REGISTRY_IMAGE_PRODUCTION:buildcache,mode=max \
--import-cache type=registry,ref=$GAR_REGISTRY_IMAGE_PRODUCTION:buildcache \
--output type=image,name=$GAR_REGISTRY_IMAGE_PRODUCTION:$CI_COMMIT_SHORT_SHA,push=true
It seems like cache is still not being used:
Looking at the build logs, cache export completes suspiciously fast:
|
After a few more trials, it seems to be completely random when it works and when it does not. When it works, it completes in a few seconds. When it doesn't... Is this a known issue? |
@gajus is that a Google Artifact Repository issue or a Docker issue? |
I had the same issue with GitLab's registry too, so I doubt it is GAR issue. |
I have same issue with Artifactory Docker Registry.
|
Hi everyone! Can someone clarify the difference between a common docker image manifest and the one that buildkit creates for cache? |
So the fix here is basically to not use GCR and use GAR instead? Edit: I can confirm that after switching to GAR the error is gone. |
I know this is closed, but leaving it here for people experiencing similar errors when porting GCR to GAR: It's worth noting that there is now an additional element in the repository path... You can experience this 400 BAD_REQUEST error when you don't add that in. For example:
Works fine, but creating a GAR repository called
Will give a BAD_REQUEST that looks a lot like this error. You need to specify the container name within the repository:
Happy artifacting 😎 |
I'm running into the same issue. Was anyone able to get it to work for caching with ECR? |
Do not close this issue, it still happening |
GCR is deprecated, and will be shut down in 2024. |
Same issue for ECR. I tried |
It does work with ECR, it needs |
Related to #720 that currently has a gcr specific workaround in the pull code.
When exporting a manifest list that contains the cache metadata for a build (eg. with mode max), the upload fails in gcr with 400 error.
There was a report in slack that it also failed with 404 https://dockercommunity.slack.com/archives/C7S7A40MP/p1566224768282100 (hence similarities with #720) but couldn't repro that.
After pushing all the blobs manifest list push fails with:
@mattmoor @dmcgowan
The text was updated successfully, but these errors were encountered: