-
Notifications
You must be signed in to change notification settings - Fork 600
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
BUILDX_NO_DEFAULT_ATTESTATIONS
not respected after v5.3.0
#1339
Comments
BUILDX_NO_DEFAULT_ATTESTATIONS
not respected after v5.4.0BUILDX_NO_DEFAULT_ATTESTATIONS
not respected after v5.3.0
I looked at changes made between
We would need full logs of |
When I just make single change from 5.2.0 to 5.3.0. It breaks with the mentioned error.
Here with 5.3.0 (stripped some internal stuff from there): |
I can actually now see what is going wrong. In
But in
|
Thanks I'm taking a look |
I was able to repro. With
But with
I'm investigating on this issue and keep you posted. |
It looks related to this change in our actions-toolkit docker/actions-toolkit@v0.18.0...v0.19.0#diff-52c8c47c24f59e49e8d73143d55935e281ac179a8483b9fd8a53a479a524885fR135-R136 where buildkit version was not detected correctly and therefore in build-push-action: build-push-action/src/context.ts Line 267 in 84ad562
This condition is satisfied because BuildKit >= 0.11.0 so this is working as expected but I think we should also take into account |
Contributing guidelines
I've found a bug, and:
Description
We have been successfully building multi arch images with native GHA runners. But when updating
build-push-action
we noticed thatBUILDX_NO_DEFAULT_ATTESTATIONS=1
no longer works in latest version of the action (v6.x). I was able to find that this got broken already in v5.3.0. We were previously using v5.0.0 so the jump to the latest version was quite large version bump.(We on purpose do not use any QEMU based approaches for building the images. These are also private images we are building.)
Expected behaviour
docker manifest create
should work in the example YAML workflow.Actual behaviour
docker manifest create
breaks with the cryptic errormyregistry/myrepo:mytest-amd64 is a manifest list
. This means that the arch specific images got some attestation data in them althoughBUILDX_NO_DEFAULT_ATTESTATIONS=1
was used as documented.Repository URL
No response
Workflow run URL
No response
YAML workflow
Workflow logs
Error:
myregistry/myrepo:mytest-amd64 is a manifest list
from docker manifest createThe text was updated successfully, but these errors were encountered: