[CI]: Release Image workflow fails to push to Alicloud ACR due to default buildx provenance attestations

[loveRhythm1990]

What happened

The Release Image workflow has failed on every run since 2026-08-21. No operator nightly image has been published since 2026-07-14.

The Build step fails when pushing to Alicloud Container Registry:

#36 pushing layers 8.9s done
#36 pushing manifest for registry.cn-hangzhou.aliyuncs.com/mocloud/matrixone-operator:nightly-d261876-2026-08-22@sha256:5065870... 1.9s done
#36 ERROR: failed to push registry.cn-hangzhou.aliyuncs.com/mocloud/matrixone-operator:nightly-d261876-2026-08-22: denied: unknown manifest class for application/vnd.oci.empty.v1+json
ERROR: failed to build: failed to solve: failed to push ...

Note the ordering: layers and the image manifest are pushed successfully, and only the final step fails. The rejected object is the provenance attestation manifest, not the image itself.

Root cause

Since BuildKit v0.11, buildx build --push attaches a provenance attestation by default. The attestation is carried in the OCI image index via a descriptor whose config mediaType is application/vnd.oci.empty.v1+json. Alicloud ACR does not recognise that mediaType and rejects the push with denied. Docker Hub accepts it, so only the ACR targets fail.

.github/workflows/release_image.yml pins old actions:

uses: docker/setup-buildx-action@v1   # does not pin a buildx version, installs latest
uses: docker/build-push-action@v2     # too old to expose a `provenance` input

Because setup-buildx-action@v1 installs whatever buildx is current, the workflow's behaviour changed without the workflow file changing.

Evidence this is environmental drift, not a code regression

Run	Result	Title
2026-08-22	failure	ci: publish prepackaged Helm charts (#612)
2026-08-22	failure	fix: upgrade bundled Kruise chart to v1.8.3 (#611)
2026-08-21	failure	ci: prevent stale generated artifacts after tool upgrades (#608)
2026-08-21	failure	fix: preserve user-defined fileservice cache fields (#607)
2026-07-14	success	fix: generate cn monitor service like dn/log (#601)

All four failures share the identical error. The first failure (#607) predates the Kruise chart work, and neither #607 nor #608 touched Dockerfile or release_image.yml. The breakage therefore landed between 2026-07-14 and 2026-08-21, via a buildx upgrade on the GitHub runners.

Failing run for reference: https://github.com/matrixorigin/matrixone-operator/actions/runs/32574827573/job/97035509626

Impact

• No operator nightly image published since 2026-07-14.
• Not blocking the Kruise 1.8.3 chart upgrade work: the GitOps new-dev deployment pins nightly-6dd5f4b-2026-06-02, which predates the breakage. Any future operator image bump is blocked until this is fixed.

Proposed fix

Minimal change, independent of action versions — set the buildx-native environment variable on the Build step:

      - name: Build
        uses: docker/build-push-action@v2
        env:
          BUILDX_NO_DEFAULT_ATTESTATIONS: 1

This disables the default attestations, so the pushed artifact is a plain image index that ACR accepts.

Follow-up (separate change)

release_image.yml still uses actions/checkout@v3, docker/login-action@v1, docker/setup-buildx-action@v1 and docker/build-push-action@v2, all of which target Node 20 and are now force-run on Node 24 with deprecation warnings:

##[warning]Node.js 20 is deprecated. The following actions target Node.js 20 but are being
forced to run on Node.js 24: actions/cache@v4, actions/checkout@v3, docker/build-push-action@v2, ...

Upgrading these (and switching to an explicit provenance: false on build-push-action@v6) should be done in a separate PR, so that restoring publishing is not entangled with an action-version bump.