Pin the released images by digest in `release.k8s.yaml` / `release.yaml`

[jboewer]

Feature request

The published install manifests reference the controller/watcher/webhook images by mutable tag only, e.g. for v0.50.0:

ghcr.io/tektoncd/pipelines-as-code/pipelines-as-code-controller:v0.50.0
ghcr.io/tektoncd/pipelines-as-code/pipelines-as-code-watcher:v0.50.0
ghcr.io/tektoncd/pipelines-as-code/pipelines-as-code-webhook:v0.50.0

Would you be open to additionally pinning these to an immutable digest, i.e. …:v0.50.0@sha256:…? Tekton Pipelines' release manifest already does this for every image, so applying a pinned PaC release would then be fully reproducible in the same way.

Use case

Consumers who vendor the release manifest for supply-chain reasons (air-gapped installs, checksum-pinned GitOps, registry mirroring) currently get a manifest whose bytes are fixed but whose image contents are not.

[chmouel]

sounds good to me just add the tag as comment, near the tag thanks

[chmouel]

lmk if you want to take this on or rather not

[jboewer]

What a quick response :D

I briefly skimmed through the release pipelines and I think I'd skip implementing this myself. I might be reading it wrong, but it seams like the container build/push is done in .github/workflows/container.yaml while the release manifest is generated separately over in the Tekton pipeline (hack/generate-releaseyaml.sh).

So to pin the digest you'd have to carry it from the ko build across to the manifest generation, and since those two run independently there's a decent chance of a race.
I think it's not really something I can test properly from outside your release infra. wdyt?

[chmouel]

yeah might be the tricky part i'll see if there is a better way to do this, thanks