-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Populate the *Run.Status.Provenance.ConfigSource
field
#5397
Populate the *Run.Status.Provenance.ConfigSource
field
#5397
Conversation
Skipping CI for Draft Pull Request. |
/test all |
The following is the coverage report on the affected files.
|
/test tekton-pipeline-unit-tests |
000f52f
to
4374be0
Compare
/test all |
The following is the coverage report on the affected files.
|
/retest |
1 similar comment
/retest |
/assign |
Oh, and this should be done for |
Yeah, that's what I planned to do in this PR. I just did for |
4374be0
to
1361c80
Compare
/test all |
The following is the coverage report on the affected files.
|
1361c80
to
447e2e5
Compare
Slight preference for merging the PRs setting the source value in resolver first and then merging this with the e2e test (since this pr enables the feature). |
64ed534
to
135c6ac
Compare
The following is the coverage report on the affected files.
|
135c6ac
to
741924b
Compare
The following is the coverage report on the affected files.
|
741924b
to
00f1d32
Compare
That makes perfect sense to me! PRs for all resolvers were merged and e2e test is added. Please take a look! Thank you @dibyom . |
The following is the coverage report on the affected files.
|
/retest |
/unhold |
This seems to be already documented in https://github.com/tektoncd/pipeline/blob/main/docs/pipelineruns.md#the-status-field |
Prior, remote `ResolutionRequest` CRD supports **recording** the source information in its Status that identifies where the remote resource came from. Similarly, `TaskRun/PipelineRun` CRD supports **receiving** the source information via a field in its status from remote ResolutionRequest. Specifically, this field named `ConfigSource` is a subfield of the `Provenance` field in status. In this PR, we are trying to pass the data from `ResolutionRequest` to pipeline reconciler so that the data can be captured in TaskRun/PipelineRun's `Status.Provenance.ConfigSource`. The implication of this change is that many functions' interface has been changed because we are passing this extra source data alongside the remote resoure. Note: - The `provenance` field in Run.status is behind a feature flag named `enable-provenance-in-status` , which was introduced in tektoncd#5670. The field will be populated iff the flag is set to `true`. - If a pipeline yaml is from remote place A, and the individual tasks are from other remote places, pipelinerun status will only record the source for the pipeline, and the individual taskrun status will record the source for the corresponding task. Related PRs/Issues: - tektoncd#5580 - tektoncd#5551 - tektoncd#5670 - tektoncd#5522 Signed-off-by: Chuang Wang <chuangw@google.com>
Thank you for all the work through the many iterations on this @chuangw6 🎉 /lgtm |
00f1d32
to
55744ed
Compare
The following is the coverage report on the affected files.
|
Coverage drop is oci/resolver is due to one line being split into two (thanks @chuangw6 ). So again: /lgtm |
Thank you so much everyone for the thorough review on this PR. @abayer @jagathprakash @Yongxuanzhang @alhuizenga @dibyom @wlynch!! Started with the PoC which passed the data through unstructured annotations to the current approach which passes through the structured fields in status, this PR enables Chains to capture the important information in the provenance in a way that is extensible and easy to maintain. Special thanks to @wlynch @dibyom for the suggestion of introducing the structured fields into |
Related to tektoncd#521 and tektoncd/pipeline#5397 Prior to this PR, `invocation.configSource` section in slsa provenance was missing. In this change, we want to record the configSource information for the remote resources i.e. git, bundle, catalog. Signed-off-by: Chuang Wang <chuangw@google.com>
Related to tektoncd#521 and tektoncd/pipeline#5397 Prior to this PR, `invocation.configSource` section in slsa provenance was missing. In this change, we want to record the configSource information for the remote resources i.e. git, bundle, catalog. Signed-off-by: Chuang Wang <chuangw@google.com>
Related to tektoncd#521 and tektoncd/pipeline#5397 Prior to this PR, `invocation.configSource` section in slsa provenance was missing. In this change, we want to record the configSource information for the remote resources i.e. git, bundle, catalog. Signed-off-by: Chuang Wang <chuangw@google.com>
Changes
Before:
Prior, remote
ResolutionRequest
CRD supports recording the source informationin its Status that identifies where the remote resource came from.
Similarly,
TaskRun/PipelineRun
CRD supports receiving the source informationvia a field in its status from remote ResolutionRequest. Specifically,
this field named
ConfigSource
is a subfield of theProvenance
field in status.Now:
In this PR, we are trying to pass the data from
ResolutionRequest
to pipelinereconciler so that the data can be captured in TaskRun/PipelineRun's
Status.Provenance.ConfigSource
.The implication of this change is that many functions' interface has been
changed because we are passing this extra source data alongside the remote resoure.
Note:
provenance
field in Run.status is behind a feature flag namedenable-provenance-in-status
, which was introduced in Feature flag for provenance field in status #5670. The field will be populated iff
the flag is set to
true
.are from other remote places, pipelinerun status will only record the source
for the pipeline, and the individual taskrun status will record the
source for the corresponding task.
Related PRs/Issues:
Source
field inResolutionRequest.status
#5551Signed-off-by: Chuang Wang chuangw@google.com
Submitter Checklist
As the author of this PR, please check off the items in this checklist:
functionality, content, code)
/kind <type>
. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tepRelease Notes