Skip to content

Standardize OCI image labels across Tekton release images #3435

Open
Open
Standardize OCI image labels across Tekton release images#3435
tektoncd/chains
#1951
 (+3)
Assignees
TheDevCodingKen
Labels
area/roadmapIssues that are part of the project (or organization) roadmap (usually an epic)good first issueDenotes an issue ready for a new contributor, according to the "help wanted" guidelines.help wantedDenotes an issue that needs help from a contributor. Must meet "help wanted" guidelines.

Description

@waveywaves
waveywaves
opened on Jun 9, 2026

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:

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.

Activity

  1. vdemeester
    added
    area/roadmapIssues that are part of the project (or organization) roadmap (usually an epic)
    on Jun 9, 2026
  2. tekton-community-roadmap-sync
    added this to Tekton Community Roadmap v2on Jun 9, 2026
  3. github-project-automation
    moved this to Todo in Tekton Community Roadmap v2on Jun 9, 2026

  4. vdemeester commented on Jul 30, 2026

    @vdemeester
    vdemeester
    on Jul 30, 2026
    Member

    Marking this as a good candidate for community contribution — the scope is well-defined (audit each repo's ko resolve invocations, add 4 standard labels), each repo can be done independently, and no cluster access is needed.

    /good-first-issue

  5. tekton-robot commented on Jul 30, 2026

    @tekton-robot
    tekton-robot
    on Jul 30, 2026
    Contributor

    @vdemeester:
    This request has been marked as suitable for new contributors.

    Please ensure the request meets the requirements listed here.

    If this request no longer meets these requirements, the label can be removed
    by commenting with the /remove-good-first-issue command.

    Details

    In response to this:

    Marking this as a good candidate for community contribution — the scope is well-defined (audit each repo's ko resolve invocations, add 4 standard labels), each repo can be done independently, and no cluster access is needed.

    /good-first-issue

    Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

  6. tekton-robot
    added
    good first issueDenotes an issue ready for a new contributor, according to the "help wanted" guidelines.
    help wantedDenotes an issue that needs help from a contributor. Must meet "help wanted" guidelines.
    on Jul 30, 2026

  7. TheDevCodingKen commented on Jul 31, 2026

    @TheDevCodingKen
    TheDevCodingKen
    on Jul 31, 2026

    I'd love to take this on! /assign @TheDevCodingKen

  8. github-project-automation
    moved this from Todo to In Progress in Tekton Community Roadmap v2on Sep 11, 2026

  9. TheDevCodingKen commented on Sep 11, 2026

    @TheDevCodingKen
    TheDevCodingKen
    on Sep 11, 2026

    I can't seem to assign myself to this issue. But, I'll submit a PR for each of the remaining repos mentioned.

  10. vdemeester commented on Sep 14, 2026

    @vdemeester
    vdemeester
    on Sep 14, 2026
    Member

    /assign @TheDevCodingKen

  11. tekton-robot
    assigned
    TheDevCodingKen
    on Sep 14, 2026

  12. enarha commented on Oct 12, 2026

    @enarha
    enarha
    on Oct 12, 2026
    Contributor

    @waveywaves @vdemeester Why do image.source and image.url point to the same thing, the source repo? For image.source that makes sense. Not sure about image.url, shouldn't it point to the repo where the image is pushed?

  13. aThorp96 commented on Oct 12, 2026

    @aThorp96
    aThorp96
    on Oct 12, 2026
    Member

    Here's the spec for these annotations: https://specs.opencontainers.org/image-spec/annotations/

    I agree with Emil here. From the spec:

    • org.opencontainers.image.source URL to get source code for building the image (string)
    • org.opencontainers.image.url URL to find more information on the image (string)

    I think the repo URL could be interpreted to be both "where to get the source code" and "where to find more info on the image", but it doesn't seem to me like the best use of the fields to include the same URL in there twice.

    What do you think about --image-label=org.opencontainers.image.source=https://github.com/tektoncd/<repo>/tree/$(params.versionTag) or "--image-label=org.opencontainers.image.source=https://github.com/tektoncd/<repo>/tree/$(git rev-parse --short HEAD)", and either leaving org.opencontainers.image.url as-is or setting it to https://github.com/tektoncd/<repo>/releases/tags/$(params.versionTag)?

  14. enarha commented on Oct 13, 2026

    @enarha
    enarha
    on Oct 13, 2026
    Contributor

    Here's the spec for these annotations: https://specs.opencontainers.org/image-spec/annotations/

    I agree with Emil here. From the spec:

    • org.opencontainers.image.source URL to get source code for building the image (string)
    • org.opencontainers.image.url URL to find more information on the image (string)

    I think the repo URL could be interpreted to be both "where to get the source code" and "where to find more info on the image", but it doesn't seem to me like the best use of the fields to include the same URL in there twice.

    Exactly my point. If image.url was standalone, indeed it's open to interpretation. But if it comes together with image.source which is straightforward, then IMO image.url should not repeat that.

    What do you think about --image-label=org.opencontainers.image.source=https://github.com/tektoncd/<repo>/tree/$(params.versionTag) or "--image-label=org.opencontainers.image.source=https://github.com/tektoncd/<repo>/tree/$(git rev-parse --short HEAD)", and either leaving org.opencontainers.image.url as-is or setting it to https://github.com/tektoncd/<repo>/releases/tags/$(params.versionTag)?

    Including specific commit is even better. My only concern is that those variables will be available in the workflow, but I see we also use a shell script release.sh like here: https://github.com/tektoncd/results/pull/1499/changes and in that case those variables won't be available. The git rev-parse will work though. Re image.url, IMO we should try to set it, the best way we can (the most accurate we can). Avoiding the default values is the requirement here, isn't it?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

area/roadmapIssues that are part of the project (or organization) roadmap (usually an epic)good first issueDenotes an issue ready for a new contributor, according to the "help wanted" guidelines.help wantedDenotes an issue that needs help from a contributor. Must meet "help wanted" guidelines.

Type

No type

Projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions