-
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
Add Source
field in ResolutionRequest.status
#5551
Add Source
field in ResolutionRequest.status
#5551
Conversation
Skipping CI for Draft Pull Request. |
ResolutionRequest.status
/test check-pr-has-kind-label |
@abayer: The specified target(s) for
The following commands are available to trigger optional jobs:
Use 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. |
/test all |
7d7b903
to
4c66e94
Compare
ResolutionRequest.status
ResolutionRequest.status
The following is the coverage report on the affected files.
|
/retest |
1 similar comment
/retest |
|
||
// Source returns the source references of the data. None atm. | ||
func (*myResolvedResource) Source() *v1alpha1.ConfigSource { | ||
return nil | ||
} |
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.
Hey @abayer
RE: "So there's the additional problem that we can't guarantee structured resolution source information - that's going to depend on the resolver implementation itself. We can control that for git, bundles, cluster, and hub, but not for any third-party resolvers that are written." from #5529 (comment)
I feel like the individual resolver implementation just needs to implement the Source()
method to return a configsource, which is part of framework.ResolvedResource
interface. This resolver template is an example. That said, I think we just need to update this section in how-to-write-a-resolver to mention this Source()
method other than Data()
and Annotations()
.
Thoughts on this?
Thank you!
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.
Updated how-to-write-a-resolver
doc in this PR. Please take a look.
@chuangw6: The
The following commands are available to trigger optional jobs:
Use 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. |
/retest |
4c66e94
to
8dabb8c
Compare
The following is the coverage report on the affected files.
|
Change 1: Add a Provenance field in TaskRun&PipelineRun status that currently only contains configsource data, but can be extended later to have more provenance-related fields. Change 2: Prior, tektoncd#5551 introduced the ConfigSource to api/resolution alpha & beta package. In this PR, we moved the ConfigSource to api/pipeline alpha & beta package for the provenance field to reuse that type (cannot import the api/resolution alpha because of import cycle). Why: See the motivation and discussions in tektoncd#5550. The tldr is that it helps pass provenance-related data in a more structured way ConfigSource is one example. Signed-off-by: Chuang Wang <[email protected]>
Change 1: Add a Provenance field in TaskRun&PipelineRun status. This field currently only contains a subfield named `ConfigSource`, but can be extended later to have more provenance-related fields. Change 2: Prior, tektoncd#5551 introduced the ConfigSource to api/resolution alpha & beta package. In this PR, we moved the ConfigSource to api/pipeline alpha & beta package for the provenance field to reuse that type (cannot import the api/resolution alpha because of import cycle). Why: See the motivation and discussions in tektoncd#5550. The tldr is that it helps pass provenance-related data in a more structured way ConfigSource is one example. Signed-off-by: Chuang Wang <[email protected]>
Change 1: Add a Provenance field in TaskRun&PipelineRun status. This field currently only contains a subfield named `ConfigSource`, but can be extended later to have more provenance-related fields. Change 2: Prior, tektoncd#5551 introduced the ConfigSource to api/resolution alpha & beta package. In this PR, we moved the ConfigSource to api/pipeline alpha & beta package for the provenance field to reuse that type (cannot import the api/resolution alpha because of import cycle). Why: See the motivation and discussions in tektoncd#5550. The tldr is that it helps pass provenance-related data in a more structured way ConfigSource is one example. Signed-off-by: Chuang Wang <[email protected]>
Change 1: Add a Provenance field in TaskRun&PipelineRun status. This field currently only contains a subfield named `ConfigSource`, but can be extended later to have more provenance-related fields. Change 2: Prior, tektoncd#5551 introduced the ConfigSource to api/resolution alpha & beta package. In this PR, we moved the ConfigSource to api/pipeline alpha & beta package for the provenance field to reuse that type (cannot import the api/resolution alpha because of import cycle). Why: See the motivation and discussions in tektoncd#5550. The tldr is that it helps pass provenance-related data in a more structured way ConfigSource is one example. Signed-off-by: Chuang Wang <[email protected]>
Change 1: Add a Provenance field in TaskRun&PipelineRun status. This field currently only contains a subfield named `ConfigSource`, but can be extended later to have more provenance-related fields. Change 2: Prior, tektoncd#5551 introduced the ConfigSource to api/resolution alpha & beta package. In this PR, we moved the ConfigSource to api/pipeline alpha & beta package for the provenance field to reuse that type (cannot import the api/resolution alpha because of import cycle). Why: See the motivation and discussions in tektoncd#5550. The tldr is that it helps pass provenance-related data in a more structured way ConfigSource is one example. Signed-off-by: Chuang Wang <[email protected]>
Change 1: Add a Provenance field in TaskRun&PipelineRun status. This field currently only contains a subfield named `ConfigSource`, but can be extended later to have more provenance-related fields. Change 2: Prior, tektoncd#5551 introduced the ConfigSource to api/resolution alpha & beta package. In this PR, we moved the ConfigSource to api/pipeline alpha & beta package for the provenance field to reuse that type (cannot import the api/resolution alpha because of import cycle). Why: See the motivation and discussions in tektoncd#5550. The tldr is that it helps pass provenance-related data in a more structured way ConfigSource is one example. Signed-off-by: Chuang Wang <[email protected]>
Change 1: Add a Provenance field in TaskRun&PipelineRun status. This field currently only contains a subfield named `ConfigSource`, but can be extended later to have more provenance-related fields. Change 2: Prior, tektoncd#5551 introduced the ConfigSource to api/resolution alpha & beta package. In this PR, we moved the ConfigSource to api/pipeline alpha & beta package for the provenance field to reuse that type (cannot import the api/resolution alpha because of import cycle). Why: See the motivation and discussions in tektoncd#5550. The tldr is that it helps pass provenance-related data in a more structured way ConfigSource is one example. Signed-off-by: Chuang Wang <[email protected]>
Change 1: Add a Provenance field in TaskRun&PipelineRun status. This field currently only contains a subfield named `ConfigSource`, but can be extended later to have more provenance-related fields. Change 2: Prior, tektoncd#5551 introduced the ConfigSource to api/resolution alpha & beta package. In this PR, we moved the ConfigSource to api/pipeline alpha & beta package for the provenance field to reuse that type (cannot import the api/resolution alpha because of import cycle). Why: See the motivation and discussions in tektoncd#5550. The tldr is that it helps pass provenance-related data in a more structured way ConfigSource is one example. Signed-off-by: Chuang Wang <[email protected]>
Change 1: Add a Provenance field in TaskRun&PipelineRun status. This field currently only contains a subfield named `ConfigSource`, but can be extended later to have more provenance-related fields. Change 2: Prior, #5551 introduced the ConfigSource to api/resolution alpha & beta package. In this PR, we moved the ConfigSource to api/pipeline alpha & beta package for the provenance field to reuse that type (cannot import the api/resolution alpha because of import cycle). Why: See the motivation and discussions in #5550. The tldr is that it helps pass provenance-related data in a more structured way ConfigSource is one example. Signed-off-by: Chuang Wang <[email protected]>
Change 1: Add a Provenance field in TaskRun&PipelineRun status. This field currently only contains a subfield named `ConfigSource`, but can be extended later to have more provenance-related fields. Change 2: Prior, tektoncd#5551 introduced the ConfigSource to api/resolution alpha & beta package. In this PR, we moved the ConfigSource to api/pipeline alpha & beta package for the provenance field to reuse that type (cannot import the api/resolution alpha because of import cycle). Why: See the motivation and discussions in tektoncd#5550. The tldr is that it helps pass provenance-related data in a more structured way ConfigSource is one example. Signed-off-by: Chuang Wang <[email protected]>
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 PipelineRun.Status.Provenance.ConfigSource. Same for taskrun status. 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 individual task. Related PRs: - tektoncd#5580 - tektoncd#5551 - tektoncd#5670 Signed-off-by: Chuang Wang <[email protected]>
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: - tektoncd#5580 - tektoncd#5551 - tektoncd#5670 Signed-off-by: Chuang Wang <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 #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: - #5580 - #5551 - #5670 - #5522 Signed-off-by: Chuang Wang <[email protected]>
ResolutionRequest.status
Source
field in ResolutionRequest.status
/kind feature
Changes
resolve #5529
Before:
The
ResolutionRequestStatusFields
only has theData
field that is a stringrepresentation of the resolved content.
Now:
A new field called
Source
is now introduced to theResolutionRequestStatusFields
to record the source information of the remote data in a structured way
using the standard SLSA ConfigSource struct.
Why?
Recently there is a clear requirement that the remote source
information of the remote data should be recorded in the provenance to
link back to its origin including the resolved the commit sha when users
only provide the branch/tag name for the resolver. Without this PR, the
only way to achieve this is to pass the resolved source information through
annotations, which has a couple of the drawbacks i.e. unstructured data,
hard to maintain and to make changes in future etc. That's where this PR
comes in to solve the problem.
Once this PR is merged, #5397 should be able to pass data through this newly added field rather than annotations.
Signed-off-by: Chuang Wang [email protected]
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