build: add OCI artifact default opt-out

[crazy-max]

relates to

• revert "exporter: fix attestation manifest push order" or make it opt-in moby/buildkit#7014
• Attestations as OCI artifacts fail to push to gitlab.com when the subject manifest is new moby/buildkit#7007
• exporter: revert attestation manifest push order moby/buildkit#7015

This adds BUILDX_NO_DEFAULT_OCI_ARTIFACT=true as a compatibility escape hatch for Buildx users who need to keep provenance attestations enabled while disabling the newer OCI artifact attestation storage format.

When this environment variable is set, Buildx now sets oci-artifact=false when attestation support is available and the user did not already set oci-artifact explicitly. This keeps explicit exporter options authoritative, mirrors the existing BUILDX_NO_DEFAULT_ATTESTATIONS compatibility pattern, and applies to both buildx build and buildx bake.

BuildKit started defaulting attestation manifests to OCI artifacts in moby/buildkit#6914 after moby/buildkit#6171 tracked registry support for that format. The issue reported in moby/buildkit#7007 showed that GitLab can still reject a push when the attestation manifest has a subject that points at a manifest that is new in the same push. The initial BuildKit-side fix in moby/buildkit#7012 changed the manifest push order, but the follow-up discussion in moby/buildkit#7014 pointed out that this is a registry compliance issue because OCI distribution requires registries to initially accept valid manifests whose subject does not exist yet.

This PR does not change the default behavior and does not make Buildx prefer the non-OCI artifact format for compliant registries. It only provides a narrow opt-out for environments that need time to deal with registry compatibility problems, while preserving provenance attestations instead of requiring users to disable them entirely with BUILDX_NO_DEFAULT_ATTESTATIONS.

[thaJeztah]

Thinking out loud; what are the formats we (currently) support for including attestations? Would it make sense to have a "attestations-format" selection instead of a boolean? (e.g. BUILDX_ATTESTATIONS_FORMAT=(oci|foo|bar|compat|legacy)) or was the old format not complying to any standards? (ISTR there were options for legacy registries, so those would still be valid and potentially work around the issue with non-OCI-compliant registries?)

[crazy-max]

I'd rather keep this as a narrow opt-out for now (specially since this change aims for a patch release). BuildKit currently exposes this as a boolean exporter option, oci-artifact=true|false, so mirroring that as BUILDX_NO_DEFAULT_OCI_ARTIFACT keeps Buildx from inventing a new format-selection layer on top.

The explicit format selection already exists through --output type=image,oci-artifact=false when users want to choose it directly. This env var only changes the default when the option was not set, similar to BUILDX_NO_DEFAULT_ATTESTATIONS.

A generic BUILDX_ATTESTATIONS_FORMAT=legacy|compat|oci feels a bit too broad to me because Buildx would then need to define what those names mean and keep mapping them to BuildKit exporter behavior. If BuildKit grows more attestation storage formats later, I think that should first be exposed as a BuildKit exporter option, and Buildx can follow that model.

[thaJeztah]

Yeah, that's ok with me; mostly wanted to avoid having to introduce yet-another env-var if there's more options than enable/disable (not even sure what format the "disable" means and if that's a legacy fallback defined by OCI?)

[thaJeztah]

Interesting; are these two the same? (I went looking if we had a more specific "supports attestations" instead of driver-name 😂)

buildx/tests/integration.go

Lines 126 to 129 in 1988826

	func isMobyWorker(sb integration.Sandbox) bool {
	name, _, hasFeature := driverName(sb.Name())
	return name == "docker" && !hasFeature
	}

buildx/tests/integration.go

Lines 136 to 139 in 1988826

	func isDockerWorker(sb integration.Sandbox) bool {
	name, _, _ := driverName(sb.Name())
	return name == "docker"
	}

[crazy-max]

Hum indeed, should rework this 😅

[thaJeztah]

LGTM