-
Notifications
You must be signed in to change notification settings - Fork 220
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TEP 0109: Better structured provenance retrieval in Tekton Chains #697
Conversation
/assign @wlynch @afrittoli |
This is a draft that I have. I'm currently working on changes to add PipelineRun into scope as well. |
teps/0108-better-structured-provenance-retrieval-in-tekton-chains.md
Outdated
Show resolved
Hide resolved
teps/0109-better-structured-provenance-retrieval-in-tekton-chains.md
Outdated
Show resolved
Hide resolved
teps/0109-better-structured-provenance-retrieval-in-tekton-chains.md
Outdated
Show resolved
Hide resolved
teps/0109-better-structured-provenance-retrieval-in-tekton-chains.md
Outdated
Show resolved
Hide resolved
teps/0109-better-structured-provenance-retrieval-in-tekton-chains.md
Outdated
Show resolved
Hide resolved
teps/0109-better-structured-provenance-retrieval-in-tekton-chains.md
Outdated
Show resolved
Hide resolved
teps/0109-better-structured-provenance-retrieval-in-tekton-chains.md
Outdated
Show resolved
Hide resolved
/assign @dibyom |
/kind tep |
bf871c5
to
d120eea
Compare
teps/0109-better-structured-provenance-retrieval-in-tekton-chains.md
Outdated
Show resolved
Hide resolved
teps/0109-better-structured-provenance-retrieval-in-tekton-chains.md
Outdated
Show resolved
Hide resolved
- name: ARTIFACT_INPUTS | ||
value: ["ARTIFACT-INPUT-NAME-1", "ARTIFACT-INPUT-NAME-1"] | ||
- name: ARTIFACT_OUTPUTS | ||
value: ["ARTIFACT-OUTPUT-NAME-1"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I prefer this over requiring task authors to plumb through result names, though a few caveats:
Putting data in object keys means that we're breaking from the intoto spec - e.g. what happens if a user just outputs a vanilla intoto material? Is intoto compatibility a goal for this proposal (it feels like this is what we're aiming for, but it's not explicitly called out as a goal)?
By putting the field in the result spec, this has the nice property of not having to need to modify the payload the Task needs to output (e.g. it can be a vanilla intoto spec), but if we'll need a spec change it might make more sense to just move forward with the status-based provenance.
4b3f310
to
b9a0aa2
Compare
teps/0109-better-structured-provenance-retrieval-in-tekton-chains.md
Outdated
Show resolved
Hide resolved
description: | | ||
The source distribution | ||
* uri: resource uri of the artifact. | ||
* digest: revision digest in form of algorithm:digest. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we have a way of representing variable length outputs? e.g. how the IMAGES
field works today.
I'm trying to think through how things where we may not know the exact # of artifacts produced like multiarch images can be supported. 🤔
- name: ARTIFACT_INPUTS | ||
value: ["ARTIFACT-INPUT-NAME-1", "ARTIFACT-INPUT-NAME-1"] | ||
- name: ARTIFACT_OUTPUTS | ||
value: ["ARTIFACT-OUTPUT-NAME-1"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can live with it, though I think we should change the arrays - I'm not sure if there's an easy way to have the Task provide these without hardcoding them. I don't think there's a way to derive the values from the replacement context.
I just updated the schemas and removed the arrays. Let me know what you think @wlynch @afrittoli |
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/retest |
@ywluogg: PR needs rebase. 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. |
|
||
## Proposal | ||
|
||
**_Please note that the below proposal will be acted as a middle ground proposal, as it on one side definitely provides more organized structure for users to provide provenance data in Tekton TaskRuns and PipelineRuns, but on the other side that it still has a bunch of trade offs that can be resolved by another proposal mentioned in Alternatives section._** |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It might help to refocus this TEP on the desired end state, and move the middle ground impl to Implementation Plan
and/or Risks and Mitigations
.
We should also look out to fill out the sections for Drawbacks
- though I think this should focus on the end goal rather than in-between steps.
/reopen |
@ywluogg: Failed to re-open PR: state cannot be changed. The pull request cannot be reopened. In response to this:
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. |
/assign @wlynch |
Start the discussions and reviews regarding to support structured results and params in Tekton Chains