fix(ci): docker cache-export flake must not fail release deployments

[sfreudenthaler]

One line: cache-to: type=gha,mode=max,ignore-error=true in the shared deploy-docker composite (all pipeline images build through it). On v26.07.27-01 (run 30285041675) a transient GHA cache-service not_found on the cache WRITE — after every image push had succeeded — failed the deployment job and cascaded: Promote latest tag skipped (latest still points at 26.07.21-01), Release Notes skipped (empty release body), changelog publish skipped. A build-speed optimization should never be able to do that.

Closes: #36744

🤖 Generated with Claude Code

https://claude.ai/code/session_012ogYXVeZsBVUHkwzdStYPJ

[claude]

Claude finished @sfreudenthaler's task in 35s —— View job

---

Code Review

• Gather context (read diff + full deploy-docker/action.yml)
• Analyze the change
• Post review

New Issues

No issues found.

The change is correct and well-targeted. Adding ignore-error=true to cache-to: type=gha,mode=max (.github/actions/core-cicd/deployment/deploy-docker/action.yml:225) makes a failed cache export non-fatal while leaving pull, push, and the build itself fully error-checked. Since the cache write happens after image layers are built and pushed, a transient GHA cache-service not_found on the write is purely a lost build-speed optimization — exactly the failure mode described in #36744. The option is valid for docker/build-push-action@v6.15.0 / buildx v0.23.0.

Assessment of the review dimensions:

• Blast radius — This composite is shared by all pipeline images, so the fix applies uniformly. That's the intended scope: it narrows blast radius by preventing a write-side cache flake from cascading into skipped Promote latest, Release Notes, and changelog steps. ✅
• Error paths — Only the non-critical cache export is now tolerant. push failures still fail the job. ✅
• Replay safety — No state mutation introduced; purely a flag on an optimization step. ✅
• Trade-off (informational, non-blocking) — ignore-error=true also silently swallows persistent cache-write regressions (e.g. a misconfigured backend), which would degrade build times without any signal. Acceptable given the priority (release reliability > cache-hit rate), but worth being aware of — if cache misses spike later, this will hide the cause rather than surface it.

Minor note (pre-existing, not introduced here): the file still has no trailing newline at EOF. Not worth blocking on.

Clean fix. No blocking concerns.

[wezell]

Test pipeline

[mergify]

Tick the box to add this pull request to the merge queue (same as @mergifyio queue).

• Queue this pull request