-
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
Set Source information in ResolutionRequest #5522
Comments
/assign |
ResolutionRequest
to taskrun/pipelinerun through status.Annotations
ConfigSource
from Resolvers to Run status.
…Status. Related to tektoncd#5522 Change 1: - Before: `ResolutionRequest.Status.ConfigSource` field was empty for the gitresolver. - Now: - `ResolutionRequest.Status.ConfigSource.URI` is set to be the user-provided URI for Anonymous Cloning, and is set to be the Repo's clone url for SCM API cloning. - `ResolutionRequest.Status.ConfigSource.Digest` is filled with one entry: the key is "sha1", and the value is the actual commit sha at the time of the gitresolver resolving the remote resource. - `ResolutionRequest.Status.ConfigSource.EntryPoint` is set to be the path of the task/pipeline yaml file. Change 2: - Before: The `ConfigSource` information in `ResolutionRequest` was not passed to pipeline/task reconciler. - Now: The `ConfigSource` information is not passed to pipeline/task reconciler and finally stored in pipelinerun/taskrun status.Provenance.ConfigSource field. Motivation: See tektoncd#5522 for details The tl;dr is that Tekton Chains needs to capture the source of the config file (pipeline.yaml or task.yaml) in the SLSA provenance's `predicate.invocation.configSource` field. Therefore, we need to pass the ConfigSource information from resolvers and to make it available in TaskRun/PipelineRun status. Signed-off-by: Chuang Wang <[email protected]>
…Status. Related to tektoncd#5522 Change 1: - Before: `ResolutionRequest.Status.ConfigSource` field was empty for the gitresolver. - Now: - `ResolutionRequest.Status.ConfigSource.URI` is set to be the user-provided URI for Anonymous Cloning, and is set to be the Repo's clone url for SCM API cloning. - `ResolutionRequest.Status.ConfigSource.Digest` is filled with one entry: the key is "sha1", and the value is the actual commit sha at the time of the gitresolver resolving the remote resource. - `ResolutionRequest.Status.ConfigSource.EntryPoint` is set to be the path of the task/pipeline yaml file. Change 2: - Before: The `ConfigSource` information in `ResolutionRequest` was not passed to pipeline/task reconciler. - Now: The `ConfigSource` information is not passed to pipeline/task reconciler and finally stored in pipelinerun/taskrun status.Provenance.ConfigSource field. Motivation: See tektoncd#5522 for details The tl;dr is that Tekton Chains needs to capture the source of the config file (pipeline.yaml or task.yaml) in the SLSA provenance's `predicate.invocation.configSource` field. Therefore, we need to pass the ConfigSource information from resolvers and to make it available in TaskRun/PipelineRun status. Signed-off-by: Chuang Wang <[email protected]>
…Status. Related to tektoncd#5522 Change 1: - Before: `ResolutionRequest.Status.ConfigSource` field was empty for the gitresolver. - Now: - `ResolutionRequest.Status.ConfigSource.URI` is set to be the user-provided URI for Anonymous Cloning, and is set to be the Repo's clone url for SCM API cloning. - `ResolutionRequest.Status.ConfigSource.Digest` is filled with one entry: the key is "sha1", and the value is the actual commit sha at the time of the gitresolver resolving the remote resource. - `ResolutionRequest.Status.ConfigSource.EntryPoint` is set to be the path of the task/pipeline yaml file. Change 2: - Before: The `ConfigSource` information in `ResolutionRequest` was not passed to pipeline/task reconciler. - Now: The `ConfigSource` information is not passed to pipeline/task reconciler and finally stored in pipelinerun/taskrun status.Provenance.ConfigSource field. Motivation: See tektoncd#5522 for details The tl;dr is that Tekton Chains needs to capture the source of the config file (pipeline.yaml or task.yaml) in the SLSA provenance's `predicate.invocation.configSource` field. Therefore, we need to pass the ConfigSource information from resolvers and to make it available in TaskRun/PipelineRun status. Signed-off-by: Chuang Wang <[email protected]>
…Status. Related to tektoncd#5522 Change 1: - Before: `ResolutionRequest.Status.ConfigSource` field was empty for the gitresolver. - Now: - `ResolutionRequest.Status.ConfigSource.URI` is set to be the user-provided URI for Anonymous Cloning, and is set to be the Repo's clone url for SCM API cloning. - `ResolutionRequest.Status.ConfigSource.Digest` is filled with one entry: the key is "sha1", and the value is the actual commit sha at the time of the gitresolver resolving the remote resource. - `ResolutionRequest.Status.ConfigSource.EntryPoint` is set to be the path of the task/pipeline yaml file. Change 2: - Before: The `ConfigSource` information in `ResolutionRequest` was not passed to pipeline/task reconciler. - Now: The `ConfigSource` information is not passed to pipeline/task reconciler and finally stored in pipelinerun/taskrun status.Provenance.ConfigSource field. Motivation: See tektoncd#5522 for details The tl;dr is that Tekton Chains needs to capture the source of the config file (pipeline.yaml or task.yaml) in the SLSA provenance's `predicate.invocation.configSource` field. Therefore, we need to pass the ConfigSource information from resolvers and to make it available in TaskRun/PipelineRun status. Signed-off-by: Chuang Wang <[email protected]>
…Status. Related to tektoncd#5522 Change 1: - Before: `ResolutionRequest.Status.ConfigSource` field was empty for the gitresolver. - Now: - `ResolutionRequest.Status.ConfigSource.URI` is set to be the user-provided URI for Anonymous Cloning, and is set to be the Repo's clone url for SCM API cloning. - `ResolutionRequest.Status.ConfigSource.Digest` is filled with one entry: the key is "sha1", and the value is the actual commit sha at the time of the gitresolver resolving the remote resource. - `ResolutionRequest.Status.ConfigSource.EntryPoint` is set to be the path of the task/pipeline yaml file. Change 2: - Before: The `ConfigSource` information in `ResolutionRequest` was not passed to pipeline/task reconciler. - Now: The `ConfigSource` information is not passed to pipeline/task reconciler and finally stored in pipelinerun/taskrun status.Provenance.ConfigSource field. Motivation: See tektoncd#5522 for details The tl;dr is that Tekton Chains needs to capture the source of the config file (pipeline.yaml or task.yaml) in the SLSA provenance's `predicate.invocation.configSource` field. Therefore, we need to pass the ConfigSource information from resolvers and to make it available in TaskRun/PipelineRun status. Signed-off-by: Chuang Wang <[email protected]>
…Status. Related to tektoncd#5522 Change 1: - Before: `ResolutionRequest.Status.ConfigSource` field was empty for the gitresolver. - Now: - `ResolutionRequest.Status.ConfigSource.URI` is set to be the user-provided URI for Anonymous Cloning, and is set to be the Repo's clone url for SCM API cloning. - `ResolutionRequest.Status.ConfigSource.Digest` is filled with one entry: the key is "sha1", and the value is the actual commit sha at the time of the gitresolver resolving the remote resource. - `ResolutionRequest.Status.ConfigSource.EntryPoint` is set to be the path of the task/pipeline yaml file. Change 2: - Before: The `ConfigSource` information in `ResolutionRequest` was not passed to pipeline/task reconciler. - Now: The `ConfigSource` information is not passed to pipeline/task reconciler and finally stored in pipelinerun/taskrun status.Provenance.ConfigSource field. Motivation: See tektoncd#5522 for details The tl;dr is that Tekton Chains needs to capture the source of the config file (pipeline.yaml or task.yaml) in the SLSA provenance's `predicate.invocation.configSource` field. Therefore, we need to pass the ConfigSource information from resolvers and to make it available in TaskRun/PipelineRun status. Signed-off-by: Chuang Wang <[email protected]>
…Status. Related to tektoncd#5522 Change 1: - Before: `ResolutionRequest.Status.ConfigSource` field was empty for the gitresolver. - Now: - `ResolutionRequest.Status.ConfigSource.URI` is set to be the user-provided URI for Anonymous Cloning, and is set to be the Repo's clone url for SCM API cloning. - `ResolutionRequest.Status.ConfigSource.Digest` is filled with one entry: the key is "sha1", and the value is the actual commit sha at the time of the gitresolver resolving the remote resource. - `ResolutionRequest.Status.ConfigSource.EntryPoint` is set to be the path of the task/pipeline yaml file. Change 2: - Before: The `ConfigSource` information in `ResolutionRequest` was not passed to pipeline/task reconciler. - Now: The `ConfigSource` information is not passed to pipeline/task reconciler and finally stored in pipelinerun/taskrun status.Provenance.ConfigSource field. Motivation: See tektoncd#5522 for details The tl;dr is that Tekton Chains needs to capture the source of the config file (pipeline.yaml or task.yaml) in the SLSA provenance's `predicate.invocation.configSource` field. Therefore, we need to pass the ConfigSource information from resolvers and to make it available in TaskRun/PipelineRun status. Signed-off-by: Chuang Wang <[email protected]>
…Status. Related to tektoncd#5522 Change 1: - Before: `ResolutionRequest.Status.ConfigSource` field was empty for the gitresolver. - Now: - `ResolutionRequest.Status.ConfigSource.URI` is set to be the user-provided URI for Anonymous Cloning, and is set to be the Repo's clone url for SCM API cloning. - `ResolutionRequest.Status.ConfigSource.Digest` is filled with one entry: the key is "sha1", and the value is the actual commit sha at the time of the gitresolver resolving the remote resource. - `ResolutionRequest.Status.ConfigSource.EntryPoint` is set to be the path of the task/pipeline yaml file. Change 2: - Before: The `ConfigSource` information in `ResolutionRequest` was not passed to pipeline/task reconciler. - Now: The `ConfigSource` information is not passed to pipeline/task reconciler and finally stored in pipelinerun/taskrun status.Provenance.ConfigSource field. Motivation: See tektoncd#5522 for details The tl;dr is that Tekton Chains needs to capture the source of the config file (pipeline.yaml or task.yaml) in the SLSA provenance's `predicate.invocation.configSource` field. Therefore, we need to pass the ConfigSource information from resolvers and to make it available in TaskRun/PipelineRun status. Signed-off-by: Chuang Wang <[email protected]>
…Status. Related to tektoncd#5522 Change 1: - Before: `ResolutionRequest.Status.ConfigSource` field was empty for the gitresolver. - Now: - `ResolutionRequest.Status.ConfigSource.URI` is set to be the user-provided URI for Anonymous Cloning, and is set to be the Repo's clone url for SCM API cloning. - `ResolutionRequest.Status.ConfigSource.Digest` is filled with one entry: the key is "sha1", and the value is the actual commit sha at the time of the gitresolver resolving the remote resource. - `ResolutionRequest.Status.ConfigSource.EntryPoint` is set to be the path of the task/pipeline yaml file. Change 2: - Before: The `ConfigSource` information in `ResolutionRequest` was not passed to pipeline/task reconciler. - Now: The `ConfigSource` information is not passed to pipeline/task reconciler and finally stored in pipelinerun/taskrun status.Provenance.ConfigSource field. Motivation: See tektoncd#5522 for details The tl;dr is that Tekton Chains needs to capture the source of the config file (pipeline.yaml or task.yaml) in the SLSA provenance's `predicate.invocation.configSource` field. Therefore, we need to pass the ConfigSource information from resolvers and to make it available in TaskRun/PipelineRun status. Signed-off-by: Chuang Wang <[email protected]>
…Status. Related to tektoncd#5522 Change 1: - Before: `ResolutionRequest.Status.ConfigSource` field was empty for the gitresolver. - Now: - `ResolutionRequest.Status.ConfigSource.URI` is set to be the user-provided URI for Anonymous Cloning, and is set to be the Repo's clone url for SCM API cloning. - `ResolutionRequest.Status.ConfigSource.Digest` is filled with one entry: the key is "sha1", and the value is the actual commit sha at the time of the gitresolver resolving the remote resource. - `ResolutionRequest.Status.ConfigSource.EntryPoint` is set to be the path of the task/pipeline yaml file. Change 2: - Before: The `ConfigSource` information in `ResolutionRequest` was not passed to pipeline/task reconciler. - Now: The `ConfigSource` information is not passed to pipeline/task reconciler and finally stored in pipelinerun/taskrun status.Provenance.ConfigSource field. Motivation: See tektoncd#5522 for details The tl;dr is that Tekton Chains needs to capture the source of the config file (pipeline.yaml or task.yaml) in the SLSA provenance's `predicate.invocation.configSource` field. Therefore, we need to pass the ConfigSource information from resolvers and to make it available in TaskRun/PipelineRun status. Signed-off-by: Chuang Wang <[email protected]>
…Status. Related to tektoncd#5522 Change 1: - Before: `ResolutionRequest.Status.ConfigSource` field was empty for the gitresolver. - Now: - `ResolutionRequest.Status.ConfigSource.URI` is set to be the user-provided URI for Anonymous Cloning, and is set to be the Repo's clone url for SCM API cloning. - `ResolutionRequest.Status.ConfigSource.Digest` is filled with one entry: the key is "sha1", and the value is the actual commit sha at the time of the gitresolver resolving the remote resource. - `ResolutionRequest.Status.ConfigSource.EntryPoint` is set to be the path of the task/pipeline yaml file. Change 2: - Before: The `ConfigSource` information in `ResolutionRequest` was not passed to pipeline/task reconciler. - Now: The `ConfigSource` information is not passed to pipeline/task reconciler and finally stored in pipelinerun/taskrun status.Provenance.ConfigSource field. Motivation: See tektoncd#5522 for details The tl;dr is that Tekton Chains needs to capture the source of the config file (pipeline.yaml or task.yaml) in the SLSA provenance's `predicate.invocation.configSource` field. Therefore, we need to pass the ConfigSource information from resolvers and to make it available in TaskRun/PipelineRun status. Signed-off-by: Chuang Wang <[email protected]>
…Status. Related to tektoncd#5522 Change 1: - Before: `ResolutionRequest.Status.ConfigSource` field was empty for the gitresolver. - Now: - `ResolutionRequest.Status.ConfigSource.URI` is set to be the user-provided URI for Anonymous Cloning, and is set to be the Repo's clone url for SCM API cloning. - `ResolutionRequest.Status.ConfigSource.Digest` is filled with one entry: the key is "sha1", and the value is the actual commit sha at the time of the gitresolver resolving the remote resource. - `ResolutionRequest.Status.ConfigSource.EntryPoint` is set to be the path of the task/pipeline yaml file. Change 2: - Before: The `ConfigSource` information in `ResolutionRequest` was not passed to pipeline/task reconciler. - Now: The `ConfigSource` information is not passed to pipeline/task reconciler and finally stored in pipelinerun/taskrun status.Provenance.ConfigSource field. Motivation: See tektoncd#5522 for details The tl;dr is that Tekton Chains needs to capture the source of the config file (pipeline.yaml or task.yaml) in the SLSA provenance's `predicate.invocation.configSource` field. Therefore, we need to pass the ConfigSource information from resolvers and to make it available in TaskRun/PipelineRun status. Signed-off-by: Chuang Wang <[email protected]>
…Status. Related to tektoncd#5522 Change 1: - Before: `ResolutionRequest.Status.ConfigSource` field was empty for the gitresolver. - Now: - `ResolutionRequest.Status.ConfigSource.URI` is set to be the user-provided URI for Anonymous Cloning, and is set to be the Repo's clone url for SCM API cloning. - `ResolutionRequest.Status.ConfigSource.Digest` is filled with one entry: the key is "sha1", and the value is the actual commit sha at the time of the gitresolver resolving the remote resource. - `ResolutionRequest.Status.ConfigSource.EntryPoint` is set to be the path of the task/pipeline yaml file. Change 2: - Before: The `ConfigSource` information in `ResolutionRequest` was not passed to pipeline/task reconciler. - Now: The `ConfigSource` information is not passed to pipeline/task reconciler and finally stored in pipelinerun/taskrun status.Provenance.ConfigSource field. Motivation: See tektoncd#5522 for details The tl;dr is that Tekton Chains needs to capture the source of the config file (pipeline.yaml or task.yaml) in the SLSA provenance's `predicate.invocation.configSource` field. Therefore, we need to pass the ConfigSource information from resolvers and to make it available in TaskRun/PipelineRun status. Signed-off-by: Chuang Wang <[email protected]>
…Status. Related to tektoncd#5522 Change 1: - Before: `ResolutionRequest.Status.ConfigSource` field was empty for the gitresolver. - Now: - `ResolutionRequest.Status.ConfigSource.URI` is set to be the user-provided URI for Anonymous Cloning, and is set to be the Repo's clone url for SCM API cloning. - `ResolutionRequest.Status.ConfigSource.Digest` is filled with one entry: the key is "sha1", and the value is the actual commit sha at the time of the gitresolver resolving the remote resource. - `ResolutionRequest.Status.ConfigSource.EntryPoint` is set to be the path of the task/pipeline yaml file. Change 2: - Before: The `ConfigSource` information in `ResolutionRequest` was not passed to pipeline/task reconciler. - Now: The `ConfigSource` information is not passed to pipeline/task reconciler and finally stored in pipelinerun/taskrun status.Provenance.ConfigSource field. Motivation: See tektoncd#5522 for details The tl;dr is that Tekton Chains needs to capture the source of the config file (pipeline.yaml or task.yaml) in the SLSA provenance's `predicate.invocation.configSource` field. Therefore, we need to pass the ConfigSource information from resolvers and to make it available in TaskRun/PipelineRun status. Signed-off-by: Chuang Wang <[email protected]>
…Status. Related to tektoncd#5522 Change 1: - Before: `ResolutionRequest.Status.ConfigSource` field was empty for the gitresolver. - Now: - `ResolutionRequest.Status.ConfigSource.URI` is set to be the user-provided URI for Anonymous Cloning, and is set to be the Repo's clone url for SCM API cloning. - `ResolutionRequest.Status.ConfigSource.Digest` is filled with one entry: the key is "sha1", and the value is the actual commit sha at the time of the gitresolver resolving the remote resource. - `ResolutionRequest.Status.ConfigSource.EntryPoint` is set to be the path of the task/pipeline yaml file. Change 2: - Before: The `ConfigSource` information in `ResolutionRequest` was not passed to pipeline/task reconciler. - Now: The `ConfigSource` information is not passed to pipeline/task reconciler and finally stored in pipelinerun/taskrun status.Provenance.ConfigSource field. Motivation: See tektoncd#5522 for details The tl;dr is that Tekton Chains needs to capture the source of the config file (pipeline.yaml or task.yaml) in the SLSA provenance's `predicate.invocation.configSource` field. Therefore, we need to pass the ConfigSource information from resolvers and to make it available in TaskRun/PipelineRun status. Signed-off-by: Chuang Wang <[email protected]>
…Status. Related to tektoncd#5522 Change 1: - Before: `ResolutionRequest.Status.ConfigSource` field was empty for the gitresolver. - Now: - `ResolutionRequest.Status.ConfigSource.URI` is set to be the user-provided URI for Anonymous Cloning, and is set to be the Repo's clone url for SCM API cloning. - `ResolutionRequest.Status.ConfigSource.Digest` is filled with one entry: the key is "sha1", and the value is the actual commit sha at the time of the gitresolver resolving the remote resource. - `ResolutionRequest.Status.ConfigSource.EntryPoint` is set to be the path of the task/pipeline yaml file. Change 2: - Before: The `ConfigSource` information in `ResolutionRequest` was not passed to pipeline/task reconciler. - Now: The `ConfigSource` information is not passed to pipeline/task reconciler and finally stored in pipelinerun/taskrun status.Provenance.ConfigSource field. Motivation: See tektoncd#5522 for details The tl;dr is that Tekton Chains needs to capture the source of the config file (pipeline.yaml or task.yaml) in the SLSA provenance's `predicate.invocation.configSource` field. Therefore, we need to pass the ConfigSource information from resolvers and to make it available in TaskRun/PipelineRun status. Signed-off-by: Chuang Wang <[email protected]>
…Status. Related to tektoncd#5522 Change 1: - Before: `ResolutionRequest.Status.ConfigSource` field was empty for the gitresolver. - Now: - `ResolutionRequest.Status.ConfigSource.URI` is set to be the user-provided URI for Anonymous Cloning, and is set to be the Repo's clone url for SCM API cloning. - `ResolutionRequest.Status.ConfigSource.Digest` is filled with one entry: the key is "sha1", and the value is the actual commit sha at the time of the gitresolver resolving the remote resource. - `ResolutionRequest.Status.ConfigSource.EntryPoint` is set to be the path of the task/pipeline yaml file. Change 2: - Before: The `ConfigSource` information in `ResolutionRequest` was not passed to pipeline/task reconciler. - Now: The `ConfigSource` information is not passed to pipeline/task reconciler and finally stored in pipelinerun/taskrun status.Provenance.ConfigSource field. Motivation: See tektoncd#5522 for details The tl;dr is that Tekton Chains needs to capture the source of the config file (pipeline.yaml or task.yaml) in the SLSA provenance's `predicate.invocation.configSource` field. Therefore, we need to pass the ConfigSource information from resolvers and to make it available in TaskRun/PipelineRun status. Signed-off-by: Chuang Wang <[email protected]>
ConfigSource
from Resolvers to Run status.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]>
Related to tektoncd#5522 Prior, a field named Source was introduced to ResolutionRequest status to record the source where the remote resource came from. And the individual resolvers need to implement the Source function to set the correct source value. But the method in clusterresolver returns a nil value. Now, we return correct source value with the 3 subfields: url, digest and entrypoint - url: [Kubernetes CRD namespace-scoped resource URI](https://kubernetes.io/docs/reference/using-api/api-concepts/#resource-uris) appended with UID. Example: /apis/GROUP/VERSION/namespaces/NAMESPACE/RESOURCETYPE/NAME@UID. - digest: sha256 checksum of the in-cluster resource - entrypoint: ***empty*** because the path is already available in url field. Signed-off-by: Chuang Wang <[email protected]>
Related to tektoncd#5522 Prior, a field named Source was introduced to ResolutionRequest status to record the source where the remote resource came from. And the individual resolvers need to implement the Source function to set the correct source value. But the method in clusterresolver returns a nil value. Now, we return correct source value with the 3 subfields: url, digest and entrypoint - url: [Kubernetes CRD namespace-scoped resource URI](https://kubernetes.io/docs/reference/using-api/api-concepts/#resource-uris) appended with UID. Example: /apis/GROUP/VERSION/namespaces/NAMESPACE/RESOURCETYPE/NAME@UID. - digest: sha256 checksum of the in-cluster resource - entrypoint: ***empty*** because the path is already available in url field. Signed-off-by: Chuang Wang <[email protected]>
Related to tektoncd#5522 Prior, a field named Source was introduced to ResolutionRequest status to record the source where the remote resource came from. And the individual resolvers need to implement the Source function to set the correct source value. But the method in clusterresolver returns a nil value. Now, we return correct source value with the 3 subfields: url, digest and entrypoint - url: [Kubernetes CRD namespace-scoped resource URI](https://kubernetes.io/docs/reference/using-api/api-concepts/#resource-uris) appended with UID. Example: /apis/GROUP/VERSION/namespaces/NAMESPACE/RESOURCETYPE/NAME@UID. - digest: sha256 checksum of the in-cluster resource - entrypoint: ***empty*** because the path is already available in url field. 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]>
Related to tektoncd#5522 Prior, a field named Source was introduced to ResolutionRequest status to record the source where the remote resource came from. And the individual resolvers need to implement the Source function to set the correct source value. But the method in clusterresolver returns a nil value. Now, we return correct source value with the 3 subfields: url, digest and entrypoint - url: [Kubernetes CRD namespace-scoped resource URI](https://kubernetes.io/docs/reference/using-api/api-concepts/#resource-uris) appended with UID. Example: /apis/GROUP/VERSION/namespaces/NAMESPACE/RESOURCETYPE/NAME@UID. - digest: sha256 checksum of the in-cluster resource - entrypoint: ***empty*** because the path is already available in url field. Signed-off-by: Chuang Wang <[email protected]>
Related to tektoncd#5522 Prior, a field named Source was introduced to ResolutionRequest status to record the source where the remote resource came from. And the individual resolvers need to implement the Source function to set the correct source value. But the method in clusterresolver returns a nil value. Now, we return correct source value with the 3 subfields: url, digest and entrypoint - url: [Kubernetes CRD namespace-scoped resource URI](https://kubernetes.io/docs/reference/using-api/api-concepts/#resource-uris) appended with UID. Example: /apis/GROUP/VERSION/namespaces/NAMESPACE/RESOURCETYPE/NAME@UID. - digest: hex-encoded sha256 checksum of the in-cluster resource - entrypoint: ***empty*** because the path is already available in url field. 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]>
Related to tektoncd#5522 Prior, a field named Source was introduced to ResolutionRequest status to record the source where the remote resource came from. And the individual resolvers need to implement the Source function to set the correct source value. But the method in clusterresolver returns a nil value. Now, we return correct source value with the 3 subfields: url, digest and entrypoint - url: [Kubernetes CRD namespace-scoped resource URI](https://kubernetes.io/docs/reference/using-api/api-concepts/#resource-uris) appended with UID. Example: /apis/GROUP/VERSION/namespaces/NAMESPACE/RESOURCETYPE/NAME@UID. - digest: hex-encoded sha256 checksum of the in-cluster resource - entrypoint: ***empty*** because the path is already available in url field. Signed-off-by: Chuang Wang <[email protected]>
Related to tektoncd#5522 Prior, a field named Source was introduced to ResolutionRequest status to record the source where the remote resource came from. And the individual resolvers need to implement the Source function to set the correct source value. But the method in clusterresolver returns a nil value. Now, we return correct source value with the 3 subfields: url, digest and entrypoint - url: [Kubernetes CRD namespace-scoped resource URI](https://kubernetes.io/docs/reference/using-api/api-concepts/#resource-uris) appended with UID. Example: /apis/GROUP/VERSION/namespaces/NAMESPACE/RESOURCETYPE/NAME@UID. - digest: hex-encoded sha256 checksum of the in-cluster resource - entrypoint: ***empty*** because the path is already available in url field. Signed-off-by: Chuang Wang <[email protected]>
Related to tektoncd#5522 Prior, a field named Source was introduced to ResolutionRequest status to record the source where the remote resource came from. And the individual resolvers need to implement the Source function to set the correct source value. But the method in clusterresolver returns a nil value. Now, we return correct source value with the 3 subfields: url, digest and entrypoint - url: [Kubernetes CRD namespace-scoped resource URI](https://kubernetes.io/docs/reference/using-api/api-concepts/#resource-uris) appended with UID. Example: /apis/GROUP/VERSION/namespaces/NAMESPACE/RESOURCETYPE/NAME@UID. - digest: hex-encoded sha256 checksum of the in-cluster resource - entrypoint: ***empty*** because the path is already available in url field. Signed-off-by: Chuang Wang <[email protected]>
Related to #5522 Prior, a field named Source was introduced to ResolutionRequest status to record the source where the remote resource came from. And the individual resolvers need to implement the Source function to set the correct source value. But the method in clusterresolver returns a nil value. Now, we return correct source value with the 3 subfields: url, digest and entrypoint - url: [Kubernetes CRD namespace-scoped resource URI](https://kubernetes.io/docs/reference/using-api/api-concepts/#resource-uris) appended with UID. Example: /apis/GROUP/VERSION/namespaces/NAMESPACE/RESOURCETYPE/NAME@UID. - digest: hex-encoded sha256 checksum of the in-cluster resource - entrypoint: ***empty*** because the path is already available in url field. 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]>
Issues go stale after 90d of inactivity. /lifecycle stale Send feedback to tektoncd/plumbing. |
Stale issues rot after 30d of inactivity. /lifecycle rotten Send feedback to tektoncd/plumbing. |
/close done! |
@chuangw6: Closing this issue. 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. |
Feature request
We need to enable Resolvers to capture the correct
ConfigSource
information in ResolutionRequest that identifies the source where the remote resource came from. This needs to be done for the following cases:Use case
SLSA provenance is required to capture the source of the remote config files in
predicate.invocation.configSource
section in which three fields are required: url, revision (actual commit sha) and path in source. Therefore, we need to capture the correct source information in resolvers because the moment of resolving the remote source is the time we know the source of truth. When the source information is captured in ResolutionRequest status, we will be able to pass this information to pipeline reconciler that will set the value in TaskRun/PipelineRun status so that Chains can capture the information from *Run.status.Implementation
The text was updated successfully, but these errors were encountered: