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
.github: Pin docker buildx version to v0.9.1 #23206
Conversation
From @aanm:
|
Failed with buildx v0.10.0: https://github.com/cilium/cilium/actions/runs/3963537803/jobs/6791477015 Looks like attestation landed in the image despite turning it off:
EDIT: We can see in the workflow file from the same run that provenance should be disabled: https://github.com/cilium/cilium/actions/runs/3963537803/workflow |
build-images-ci is using
So I guess the changes in this PR are ignored by CI. |
12251ba
to
0d6ebe1
Compare
Latest failure: https://github.com/cilium/cilium/actions/runs/3963649065/jobs/6791721533 Again, the workflow file shows that provenance should be disabled, but it's not: 🤷 either I'm messing up the configuration, or the provenance feature cannot be disabled by the upstream plugin. I'm going to try switching to an approach where we just pin the docker buildx version to an older version. |
Somewhere between the combination of GitHub action docker/build-push-action v3.3.0 and Docker buildx version v0.10.0, provenance attestation was transparently added into the build process for new images. Unfortunately, since we already have SBOM generation steps in our workflows, this would break the workflows. The existing workflows would attempt to pull the images with provenance and then generate an SBOM from that existing attestation. This would lead to a message like the following in CI image builds: level=fatal msg="generating doc: creating SPDX document: generating SPDX package from image ref quay.io/cilium/docker-plugin-ci:XXX: generating image package" I tried disabling provenance in the docker/build-push-action, but apparently it just ignored such requests and pushed the attestation into the image anyway. So, this commit attempts to revert buildx back to v0.9.1 to prevent it from generating those artifacts. This is a quick-and-dirty hack to stabilize CI for the short term, then we can figure out over time how to properly resolve the conflict between these systems. Signed-off-by: Joe Stringer <joe@cilium.io>
0d6ebe1
to
2076586
Compare
Looks like that did the trick, the CI action pulled docker buildx v0.9.1: https://github.com/cilium/cilium/actions/runs/3963731211/jobs/6791899664 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
pin to win
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Docker buildx is just bumped to v0.10.0 today actions/runner-images#6941, so that probably explains mixed versions as part of transition.
Pinning did not seem to fix the issue. We are removing SBOM in #23204 until we find a better fix. Should we revert this? |
This isn't working because we set |
Dropping backport labels in favour of #23220 . |
Somewhere between the combination of GitHub action
docker/build-push-action v3.3.0 and Docker buildx version v0.10.0,
provenance attestation was transparently added into the build process
for new images. Unfortunately, since we already have SBOM generation
steps in our workflows, this would break the workflows. The existing
workflows would attempt to pull the images with provenance and then
generate an SBOM from that existing attestation. This would lead to a
message like the following in CI image builds:
I tried disabling provenance in the docker/build-push-action, but
apparently it just ignored such requests and pushed the attestation into
the image anyway. So, this commit attempts to revert buildx back to
v0.9.1 to prevent it from generating those artifacts.
This is a quick-and-dirty hack to stabilize CI for the short term, then
we can figure out over time how to properly resolve the conflict between
these systems.