tektoncd
Add a new annotation field `pipeline.tekton.dev/builderVersion`
Feature request
Add a new annotation field pipeline.tekton.dev/builderVersion to capture the builder version that can be customized when installing tekton.
Use case
Use the annotation field to attach customized version string to run objects i.e. pipelinerun/taskrun, which can be used by the Chains to capture the builderVersion in attestation.
@chuangw6 what does that "builderVersion" would/can convey as information ? I am not yet sure to understand the use case there.
@chuangw6 what does that "builderVersion" would/can convey as information ? I am not yet sure to understand the use case there.
Hi @vdemeester,
The motivation here is to convey the accurate Tekton Pipeline version in a way that customers can customize the format through builderVersion.
In the SLSA community, there is a strong interest that people want to record the builder version information in the SLSA provenance. So next SLSA release is very likely to have a field for the builder version. See more details here https://github.com/slsa-framework/slsa/issues/319.
Today's slsa 0.2 spec doesn't have a field for this. However, we can use this information as the value of builder_version field in Grafeas BUILD note, and could also embed the version information in the predicate.builder.id field of SLSA 0.2 spec. Getting this information from run object rather than through Chains's configmap helps version drift problem i.e. outdated Chains configmap says the version is x, but actual builder version is x + 1.
Feel free to chime in if you have more comments/thoughts @wlynch @dibyom.
Thanks.
@chuangw6 understand, but then what differs from the pipeline.tekton.dev/release ? Do we need 2 labels/annotations or can we just make the existing one have the right set of informations ?
what differs from the
pipeline.tekton.dev/release? Do we need 2 labels/annotations or can we just make the existing one have the right set of informations ?
There's also app.kubernetes.io/version and version that also look like they serve a similar purpose. 😂
It would be great to consolidate these, or at the very least take inventory of what each label is used for.
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale with a justification.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.
/lifecycle stale
Send feedback to tektoncd/plumbing.
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten with a justification.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.
/lifecycle rotten
Send feedback to tektoncd/plumbing.
Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen with a justification.
Mark the issue as fresh with /remove-lifecycle rotten with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.
/close
Send feedback to tektoncd/plumbing.
@tekton-robot: Closing this issue.
In response to this:
Rotten issues close after 30d of inactivity. Reopen the issue with
/reopenwith a justification. Mark the issue as fresh with/remove-lifecycle rottenwith a justification. If this issue should be exempted, mark the issue as frozen with/lifecycle frozenwith a justification./close
Send feedback to tektoncd/plumbing.
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.