Introduce new `attestation` exporter options by jedevc · Pull Request #3403 · moby/buildkit

jedevc · 2022-12-14T12:37:04Z

These replace the inline-only attestation fields introduce in #3342.

Instead, we can now specify attestations=<true/false/filter-list> per exporter, to enable specific attestation per exporter - the default in buildkit is set to true. The possible values are:

true: output all provided attestations from the solver
false: output none of the provided attestations from the solver
reason,[reasons]: a csv list of reasons, outputs only the attestations that were generated for one of those specified reasons, using the metadata field. e.g. --output type=...,attestations=provenance will only include provenance attestations in the output for that exporter, even if other attestations (like SBOMs) were generated in the solver.

We also update the attestation-prefix option to be attestation[s]-prefix - to be more aligned with the new attestations flag.

Additionally, we have a few smaller minor refactoring commits around the exporter:

Propogate metadata through unbundling (wasn't causing any issues now, but could in the future, since logically we should inherit metadata through the process)
Moves fs opt parsing into shared logic between the local+tar exporters, so we don't need to duplicate all of that.
Removes non-dist options from the tar exporter (introduced in Do not re-tag non-distributable blob descriptors #2561) - these aren't ever used, so we can silently drop them. If clients were using this, no error will occur, it will just silently do nothing.

tonistiigi

I'm not convinced we should remove inline-only. I think this is the correct way for client to ask for expected behavior without knowing too much about the internals. I don't mind a way to skip attestation on exporter level as well if there is a use case.

jedevc · 2022-12-16T11:12:20Z

Removed inline-only in #3420 - we shouldn't block the rest of the changes on that.

tonistiigi · 2022-12-20T22:04:32Z

+	}
+
+	for _, att := range attestations {
+		target, ok := att.Metadata[result.AttestationReasonKey]


Not from this PR but I don't understand why this is called a "reason". It is attestation type. So why can't we just use the already existing predicate type field?

Signed-off-by: Justin Chadwell <me@jedevc.com>

This allows one implementation for all the opts parsing, similar to how we do today for the ImageCommitOpts. Additionally, we rename attestation-prefix to attestations-prefix (pluralized) to prepare for the new attestations option. Signed-off-by: Justin Chadwell <me@jedevc.com>

This option looks like a mistake added in 45fc3ed. These options aren't ever used, so we don't need to parse them, we can just silently discard them. Signed-off-by: Justin Chadwell <me@jedevc.com>

Signed-off-by: Justin Chadwell <me@jedevc.com>

Instead of just the boolean true/false values, we allow the attestation option for exporters to contain an arbitrary list of "attestation reasons". Only attestations that have a reason matching the list will actually be output. This allows clients to completely detach the concepts of "what attestations to generate" and "what attestations to output". Signed-off-by: Justin Chadwell <me@jedevc.com>

@tag

`ARG TARGETARCH=amd64` (with a default) silently shadows BuildKit's per-platform auto-inject (moby/buildkit#3403). Consequence: every multi-arch build of this Dockerfile — including every `:vX.Y.Z` and `:latest` pushed to GHCR by release-test-tools.yaml since v0.9.10 — ran its `case` branch with TARGETARCH=amd64 *regardless of target platform*. The arm64 variant therefore shipped x86_64 shellcheck and hadolint binaries; downstream CI on arm64 runners fails at `shellcheck: Exec format error` the first time it consumes test-tools on arm64 (caught by ros1_bridge PR #27 enabling the arm64 matrix). Fix: drop the default. `ARG TARGETARCH` (bare declaration) lets BuildKit auto-inject take effect. Outside BuildKit, pass `--build-arg TARGETARCH=<arch>` explicitly — the `case` default branch already fails loud on empty TARGETARCH so nobody silently ships the wrong binaries. Regression test in template_spec.bats asserts the ARG has no default, plus the existing bare-declaration test continues to guarantee consumption is still wired. 674 → 675. Re-release plan: tag v0.10.0-rc2 after merge. release-test-tools.yaml re-runs on tag push and reissues ghcr.io/.../test-tools:v0.10.0-rc2 + :latest with correct per-arch binaries. Downstream repos on the broken v0.9.13 / v0.10.0-rc1 tags stay broken on arm64 until they bump @tag.

@tag

v0.9.13's release-test-tools.yaml shipped a multi-arch ghcr.io/ycpss91255-docker/test-tools:v0.9.13 with x86_64 shellcheck / hadolint binaries in BOTH manifest variants — the `ARG TARGETARCH=amd64` default in template/dockerfile/Dockerfile.test-tools shadowed BuildKit's per-platform auto-inject (moby/buildkit#3403), so every multi-arch run fell back to amd64. This branch enabled the arm64 matrix but kept pointing at @v0.9.13, so the arm64 shard blew up at `shellcheck: Exec format error` on first run. Template v0.10.0-rc2 (#126 / #127) drops the ARG default. The rc2 GHCR image's arm64 variant contains real aarch64 binaries (verified via `docker cp` + `file`). Bumping build-worker.yaml + release- worker.yaml @tag so this PR's arm64 shard picks up the correct image.

@tag

* ci: enable arm64 in build matrix (linux/amd64,linux/arm64) PR #23 rebuilt devel from a multi-arch base for Jetson support, but main.yaml never opted in to the template's arm64 build matrix — the build-worker.yaml input defaults to linux/amd64 only. As a result, every PR since #23 has only verified amd64 in CI; arm64 has been validated manually via rsync-to-Jetson. Pass platforms: linux/amd64,linux/arm64 to build-worker.yaml so CI runs both architectures in parallel (template v0.9.11 added the ubuntu-24.04-arm runner support). * ci: bump template @tag to v0.10.0-rc2 for arm64 test-tools fix v0.9.13's release-test-tools.yaml shipped a multi-arch ghcr.io/ycpss91255-docker/test-tools:v0.9.13 with x86_64 shellcheck / hadolint binaries in BOTH manifest variants — the `ARG TARGETARCH=amd64` default in template/dockerfile/Dockerfile.test-tools shadowed BuildKit's per-platform auto-inject (moby/buildkit#3403), so every multi-arch run fell back to amd64. This branch enabled the arm64 matrix but kept pointing at @v0.9.13, so the arm64 shard blew up at `shellcheck: Exec format error` on first run. Template v0.10.0-rc2 (#126 / #127) drops the ARG default. The rc2 GHCR image's arm64 variant contains real aarch64 binaries (verified via `docker cp` + `file`). Bumping build-worker.yaml + release- worker.yaml @tag so this PR's arm64 shard picks up the correct image.

jedevc requested a review from tonistiigi December 14, 2022 12:37

jedevc mentioned this pull request Dec 14, 2022

Better attestations default parameters using new exporter attestation options docker/buildx#1469

Closed

jedevc added this to the v0.11.0 milestone Dec 14, 2022

jedevc force-pushed the exporter-attestations-options branch from de22d35 to 2aa3f8a Compare December 14, 2022 14:29

tonistiigi reviewed Dec 14, 2022

View reviewed changes

jedevc mentioned this pull request Dec 16, 2022

Remove inline-only attestations option #3420

Closed

jedevc force-pushed the exporter-attestations-options branch from 2aa3f8a to fe28241 Compare December 16, 2022 11:07

jedevc added the area/attestations label Dec 16, 2022

tonistiigi reviewed Dec 20, 2022

View reviewed changes

jedevc mentioned this pull request Jan 5, 2023

Get attestations separate from build output #3458

Open

jedevc added 5 commits January 5, 2023 14:25

tests: fixup attestation tar to not panic when file not found

91324b5

Signed-off-by: Justin Chadwell <me@jedevc.com>

exporter: remove non dist options from tar exporter

ab91151

This option looks like a mistake added in 45fc3ed. These options aren't ever used, so we don't need to parse them, we can just silently discard them. Signed-off-by: Justin Chadwell <me@jedevc.com>

exporter: add attestations key to allow disabling attestation output

602d9f8

Signed-off-by: Justin Chadwell <me@jedevc.com>

jedevc force-pushed the exporter-attestations-options branch from fe28241 to 2488167 Compare January 5, 2023 14:30

jedevc mentioned this pull request Jan 6, 2023

Various exporter refactoring fixes #3465

Merged

jedevc closed this Jan 6, 2023

jedevc mentioned this pull request Jan 6, 2023

exporter: force enabling inline attestations for image export #3466

Merged

ycpss91255 mentioned this pull request Apr 24, 2026

fix: remove ARG TARGETARCH default in Dockerfile.test-tools ycpss91255-docker/template#126

Merged

4 tasks

ycpss91255 mentioned this pull request Apr 27, 2026

test-tools v0.9.13 multi-arch image: arm64 manifest contains x86_64 binaries ycpss91255-docker/template#125

Closed

4 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Introduce new `attestation` exporter options#3403

Introduce new `attestation` exporter options#3403
jedevc wants to merge 5 commits intomoby:masterfrom
jedevc:exporter-attestations-options

jedevc commented Dec 14, 2022 •

edited

Loading

Uh oh!

tonistiigi left a comment

Uh oh!

jedevc commented Dec 16, 2022

Uh oh!

tonistiigi Dec 20, 2022

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

jedevc commented Dec 14, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tonistiigi left a comment

Choose a reason for hiding this comment

Uh oh!

jedevc commented Dec 16, 2022

Uh oh!

tonistiigi Dec 20, 2022

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

jedevc commented Dec 14, 2022 •

edited

Loading