community
community copied to clipboard
tektoncd
TEP-0122 reproducibility of complete build instructions
This proposal outlines what information is required to reproduce complete build instructions for taskruns. It also suggests where in the provenance to store this information.
[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To complete the pull request process, please assign danielhelfand after the PR has been reviewed.
You can assign the PR to them by writing /assign @danielhelfand in a comment when ready.
The full list of commands accepted by this bot can be found here.
Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment
/assign @wlynch (@chuangw6 suggested that you might be interested in this PR 🙂 )
@afrittoli: No presubmit jobs available for tektoncd/community@main
In response to this:
/test pull-community-teps-lint
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.
@chitrangpatel: 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.
The following Tekton test failed:
| Test name | Commit | Details | Required | Rerun command |
|---|---|---|---|---|
| pull-community-teps-lint | d53871a2dc0243db6cd56147f414d72468ab77a4 | link | true | /test pull-community-teps-lint |
I had initially suggested we frame these changes around 'reproducibility' but I think that has caused some confusion (since the SLSA reproducible requirement requires very little from the build platform and I don't think we should try to go beyond that at least for now) and I think we are actually trying to meet two other SLSA provenance requirements:
I think it boils down to something like this:
- 'build instructions' for Tekton are the 'authoring time info' i.e. the Task/Pipeline defintion
- 'build parameters' for Tekton are the 'runtime info' that is provided (i.e. the info a TaskRun/PipelineRun provides in order to realize execution of at Task/Pipeline)
Our 'build instructions' are currently incomplete (or were 6 months ago anyway XD) b/c we just grab the steps and not the entire Task definition (and we need to now include Pipeline definitions for PipelineRun level provenance). If "build as code" is used, the SLSA requirement is just that we identify where the Task/Pipeline lives in version control. If it isn't, we need to reproduce the Task/Pipeline in the provenance (we can decide if we want to include it in the build as code case as well).
We also need to make sure we are including all of the param/runtime info as well. (You're probably right to include the invocation.environment info here as well BUT I think you would also be reasonable to declare that out of scope and tackle is separately)
I can certainly do that. Things around that are creating a lot of confusion and raising questions that probably cannot be answered immediately.
So TL;DR, if you agree, for clarity I'd personally rename this TEP to something like "complete build instructions and parameters" - and maybe remove requirements around reproducibility as well.
Sounds good. Updated the TEP to reflect your suggestions. Let me know what you think.
[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: afrittoli, bobcatfish, wlynch
The full list of commands accepted by this bot can be found here.
The pull request process is described here
- ~~teps/OWNERS~~ [afrittoli,bobcatfish,wlynch]
Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment