feat(publish-kustomize-bundle): multi-image composite action (draft)

[scotwells]

Summary

A composite action that stamps multiple images into a Kustomize bundle and pushes it — the case the current reusable workflow can't cover (it pins a single image). Because it runs as a step in the caller's job, it reads image tags straight from earlier build steps and stamps them all into one bundle before pushing — no separate job, no re-checkout.

Usage

- uses: actions/checkout@v4
- id: provider   # build+push provider image -> outputs.tag
- id: runtime    # build+push runtime image  -> outputs.tag
- uses: datum-cloud/actions/publish-kustomize-bundle@v1.20.0
  with:
    bundle-name: ghcr.io/datum-cloud/unikraft-provider-kustomize
    bundle-path: config
    images: |
      - { path: config/default, name: ghcr.io/datum-cloud/unikraft-provider, tag: "${{ steps.provider.outputs.tag }}" }
      - { path: config/dependencies/ukp-runtime, name: ghcr.io/datum-cloud/ukp-runtime, tag: "${{ steps.runtime.outputs.tag }}" }

Notes

• Per-image: each images entry is { path, name, tag }; tag is optional and defaults to the bundle's computed tag (only needed when images come from separate builds). Full input/output tables are in the action README.
• Caller prerequisite: composite actions can't declare secrets:, so the job must checkout, docker/login to ghcr, and grant packages: write before this step (the flux push authenticates via that login).
• Reuses the existing reusable workflow's tag + push logic; that workflow stays in place — this is the multi-image, in-job alternative.

Status

Draft sketch: actionlint + shellcheck pass, and the images parse + kustomize edit set image are proven against a scratch kustomization; not yet exercised in a live CI run.

Open question for review: keep both, or deprecate the reusable workflow? This subsumes the single-image case (a one-entry list), but the workflow's dedicated-job + secrets: inherit model is simpler for CRD-only publishes.