Reduce Docker build critical path by avoiding unnecessary pull/save/upload/load cycles

[dceoy]

Background

The Docker build workflows already use BuildKit GitHub Actions cache, but they still add expensive post-build work to the critical path: pulling pushed images back to the runner, saving tarballs, uploading artifacts, downloading artifacts, and loading images before scanning.

This issue focuses on runtime reduction. It overlaps conceptually with #669's safety concern about unconditional image tarball artifacts, but the goal here is to make the artifact path optional and avoid redundant image movement when registry-based scanning is enough.

Current state

• docker-build-and-push.yml builds with cache-from: type=gha and cache-to: type=gha,mode=max, then, when push: true, pulls the just-pushed tags back to the runner, saves them into a tarball, and uploads the tarball artifact.
• docker-buildx-bake.yml has the same pattern for bake outputs: BuildKit cache is configured, but pushed images are pulled back, saved to a tarball, and uploaded.
• Both workflows then call docker-image-scan.yml for post-build scanning.
• docker-image-scan.yml downloads the image tarball artifact and runs docker load whenever image-artifact-name is provided, before running Trivy.
• For pushed images, Trivy can usually scan the pushed image references directly after registry login; the tarball round-trip is only needed for push: false, private images unavailable by ref, or explicit offline/artifact-based scan modes.

Proposed direction

Add explicit post-build image-transfer controls and prefer the shortest scan path:

1. Add inputs to Docker build workflows:
   • upload-image-artifact defaulting to false when push: true; keep a backward-compatible transition if needed.
   • postbuild-scan-source: registry|artifact|auto, defaulting to auto.
   • pull-after-push defaulting to false, used only when a downstream step needs a local image.
2. In auto mode:
   • If push: true, pass pushed image refs/digests to docker-image-scan.yml and do not pull/save/upload/load.
   • If push: false, use load: true and artifact/local scan only when multi-platform constraints allow it.
3. For docker-buildx-bake.yml:
   • Avoid pulling all image refs after push unless artifact export is explicitly enabled.
   • Preserve the existing pull-images-if-exist behavior separately; do not conflate it with post-build artifact export.
4. For docker-image-scan.yml:
   • Make artifact download/load conditional on an explicit artifact scan mode, not merely a default artifact name propagated by the parent workflow.
   • Support registry login before Trivy image scan when scanning private pushed images by ref.
5. Keep security posture clear:
   • Document that artifact mode may expose full image contents to users with Actions artifact access.
   • Prefer digest-based image refs for registry scan to avoid tag races.

Acceptance criteria

• docker-build-and-push.yml does not pull/save/upload a pushed image unless a caller explicitly requests artifact export or local image reuse.
• docker-buildx-bake.yml does not pull/save/upload pushed bake outputs unless explicitly requested.
• docker-image-scan.yml can scan pushed private images by ref after registry login without requiring an image tarball artifact.
• push: false remains supported, with clear behavior for single-platform vs multi-platform builds.
• README documents postbuild-scan-source, upload-image-artifact, and compatibility notes for existing consumers.
• Smoke tests cover both registry/ref-scan and artifact-scan paths, using minimal images.

Relevant workflows

• .github/workflows/docker-build-and-push.yml
• .github/workflows/docker-buildx-bake.yml
• .github/workflows/docker-image-scan.yml
• .github/workflows/docker-build-with-multi-targets.yml
• .github/workflows/docker-save-and-terraform-deploy-to-aws.yml