Standardize OCI image labels across Tekton release images

Feature request

Standardize OCI image labels across Tekton release images that are produced with ko resolve.

tektoncd/pipeline#9965 adds explicit OCI image labels to the Pipeline release ko resolve invocations so images do not inherit misleading labels from base images such as ghcr.io/tektoncd/plumbing/tini-git.

If Pipeline release images set these labels explicitly, the rest of the Tekton component release images should do the same for consistency and future-proofing. Otherwise component images may inherit org.opencontainers.image.* metadata from their base images, which can make published image metadata point at the wrong project.

For each component release path, set project-specific values for at least:

--image-label=org.opencontainers.image.source=https://github.com/tektoncd/<repo> \
--image-label=org.opencontainers.image.url=https://github.com/tektoncd/<repo> \
--image-label=org.opencontainers.image.title=<repo-or-component-name> \
--image-label=org.opencontainers.image.description=<human-readable Tekton component description> \

Use the repo's existing $(params.package) / ${GITHUB_REPO} variables where available.

Related background:

• tektoncd/plumbing#2831 reports inherited plumbing/tini-git labels, including an emoji in org.opencontainers.image.description, on Pipeline resolver images.
• tektoncd/pipeline#9965 fixes this in Pipeline by setting source, url, title, and description in tekton/publish.yaml.
• tektoncd/plumbing#3434 / tektoncd/plumbing#3221 discuss a shared plumbing/static-base image; if downstream repos adopt a labeled shared base image, explicit component labels will become even more important.

Use case

Users and downstream registries should see Tekton component metadata on Tekton component images, not metadata inherited from a base image project.

For example, Pipeline resolver images inherited labels from ghcr.io/tektoncd/plumbing/tini-git, so metadata such as org.opencontainers.image.title, org.opencontainers.image.url, and org.opencontainers.image.description pointed to tektoncd/plumbing instead of tektoncd/pipeline. This can confuse users, scanners, mirrors, and registry UIs. It can also cause compatibility issues when inherited metadata contains values that downstream registries reject.

Repos / files to audit and update

Skip the pipeline-ghsa-* repos.

Known release/build paths with ko resolve to check:

• tektoncd/pipeline
  • tekton/publish.yaml
  • Covered by tektoncd/pipeline#9965
• tektoncd/chains
  • release/publish.yaml
• tektoncd/operator
  • tekton/build-publish-images-manifests.yaml
• tektoncd/results
  • tekton/publish.yaml
  • release/release.sh
• tektoncd/pruner
  • tekton/publish.yaml
  • hack/build.sh
• tektoncd/triggers
  • tekton/publish.yaml
• tektoncd/dashboard
  • scripts/installer
• tektoncd/pipelines-as-code
  • hack/generate-releaseyaml.sh
• tektoncd/plumbing
  • tekton/catalog/tasks/publish.yaml
  • any image build paths that publish shared base/tooling images

Notes from a quick scan

The current most visible inherited-label cases are:

• tektoncd/pipeline: cmd/resolvers uses ghcr.io/tektoncd/plumbing/tini-git, whose labels point to tektoncd/plumbing; fixed by tektoncd/pipeline#9965.
• tektoncd/pruner: .ko.yaml uses cgr.dev/chainguard/static:latest, which currently has OCI labels for Chainguard/static; release/build paths should override more than just source.

Other repos may not currently inherit incorrect labels from their present base images, but setting the component labels explicitly everywhere keeps release metadata consistent and avoids future regressions when base images change.

Acceptance criteria

• Active Tekton component release images publish project-specific OCI labels for source, url, title, and description.
• Release and local build scripts that use ko resolve set the same component-level metadata consistently.
• pipeline-ghsa-* repos are not included in this cleanup.
• Existing release generation checks continue to pass in each repo.