ci: target multi-arch publication checks without losing runtime-image testing

[alchemydc]

Priority: P1

Motivation

Ordinary Rust PRs currently build the runtime target twice, but the builds serve different purposes:

• test-docker.yml exports a local AMD64 image and runs nine container/configuration checks against it;
• zfnd-deploy-nodes-gcp.yml calls the reusable publication workflow, builds AMD64 and ARM64, pushes digests to GAR, creates the multi-arch manifest, and exercises attestations/publication metadata. Deploy jobs themselves skip on PRs.

Removing the deployment build from PRs is therefore an explicit reduction in per-PR ARM64 and publication-path coverage. The proposed policy is to keep that coverage on targeted PRs, all relevant main pushes, and releases—not on every source-only Rust PR.

Proposed change

1. Keep test-docker.yml triggered by ordinary Rust changes so the runtime image still compiles and its configuration behavior remains merge-blocking.
2. Restrict the deployment/publication workflow's PR trigger to inputs that can affect cross-platform or publication behavior:
   • docker/** and .dockerignore;
   • workspace/package Cargo.toml and Cargo.lock files;
   • rust-toolchain.toml and .cargo/config.toml;
   • the reusable Docker build workflow;
   • the deployment workflow;
   • any action/script directly invoked by those workflows.
3. Do not trigger the full publication path for a PR that changes only *.rs files.
4. Preserve the current full build on relevant pushes to main and releases, with failure issue reporting for non-PR failures.
5. Preserve workflow_dispatch so a maintainer can build a branch/PR image in GAR for manual testing.
6. Document the accepted tradeoff: architecture-specific source regressions can reach main; the post-merge ARM64 build remains the alerted backstop. Revisit if ARM64 failures are observed.

Acceptance criteria

• A source-only Rust PR runs the local AMD64 image/configuration path but not the full GAR publication path.
• Dockerfile, lockfile, toolchain, build-action, and publication-workflow changes run both AMD64 and ARM64 plus manifest/attestation creation.
• Relevant main pushes and releases retain the full publication path.
• Maintainers retain an explicit manual path for producing a branch/PR GAR image.
• Required check behavior remains stable when the targeted workflow does not start.
• The PR description states the ARM64 timing tradeoff rather than calling the builds identical duplicates.

---

Part of the Improve CI program (#11196)

Drafted with Claude Code from the comparative analysis and the reviewed plan; independently reviewed and corrected with OpenAI Codex. Maintainers remain responsible for validating measurements and approving coverage tradeoffs.