Rename ConfigSource to RefSource

Recently, we introduced a new field named `provenance` in *Run.satus, and
one subfield it has is named `ConfigSource`.

In this commit, we renamed the subfield `ConfigSource` to `RefSource`.

Reasoning: ConfigSource is the SLSA name and ties to a specific SLSA version.
It also makes this a leaky abstraction, i.e. we are naming fields in our API
after how we want to use them. Additionally, `config` isn't a concept that
exists in Tekton.

Backward compatibility: This field was just introduced recently as an alpha
feature gated by a dedicated feature flag. It should be okay being unstable :D.
As far as I know, it would be only a breaking change for Chains which
just started using this field recently, but I am happy to handle this in
Chains once this change is included in our next release.

Signed-off-by: Chuang Wang <chuangw@google.com>

docs/bundle-resolver.md

@@ -89,7 +89,7 @@ spec:
 ```
 
 ## `ResolutionRequest` Status
-`ResolutionRequest.Status.Source` field captures the source where the remote resource came from. It includes the 3 subfields: `url`, `digest` and `entrypoint`.
+`ResolutionRequest.Status.RefSource` field captures the source where the remote resource came from. It includes the 3 subfields: `url`, `digest` and `entrypoint`.
 - `uri`: The image repository URI
 - `digest`: The map of the algorithm portion -> the hex encoded portion of the image digest.
 - `entrypoint`: The resource name in the OCI bundle image.
@@ -148,7 +148,7 @@ status:
   ...
   data: xxx
   observedGeneration: 1
-  source:
+  refSource:
     digest:
       sha256: f51ca50f1c065acba8290ef14adec8461915ecc5f70a8eb26190c6e8e0ededaf
     entryPoint: git-clone

docs/cluster-resolver.md

@@ -82,7 +82,7 @@ spec:
 ```
 
 ## `ResolutionRequest` Status
-`ResolutionRequest.Status.Source` field captures the source where the remote resource came from. It includes the 3 subfields: `url`, `digest` and `entrypoint`.
+`ResolutionRequest.Status.RefSource` field captures the source where the remote resource came from. It includes the 3 subfields: `url`, `digest` and `entrypoint`.
 - `url`: url is the unique full identifier for the resource in the cluster. It is in the format of `<resource uri>@<uid>`. Resource URI part is the namespace-scoped uri i.e. `/apis/GROUP/VERSION/namespaces/NAMESPACE/RESOURCETYPE/NAME`. See [K8s Resource URIs](https://kubernetes.io/docs/reference/using-api/api-concepts/#resource-uris) for more details.
 - `digest`: hex-encoded sha256 checksum of the content in the in-cluster resource's spec field. The reason why it's the checksum of the spec content rather than the whole object is because the metadata of in-cluster resources might be modified i.e. annotations. Therefore, the checksum of the spec content should be sufficient for source verifiers to verify if things have been changed maliciously even though the metadata is modified with good intentions.
 - `entrypoint`: ***empty*** because the path information is already available in the url field.
@@ -130,7 +130,7 @@ status:
   annotations: ...
   conditions: ...
   data: xxx
-  source:
+  refSource:
     digest:
       sha256: 245b1aa918434cc8195b4d4d026f2e43df09199e2ed31d4dfd9c2cbea1c7ce54
     uri: /apis/tekton.dev/v1beta1/namespaces/default/task/a-simple-task@3b82d8c4-f89e-47ea-a49d-3be0dca4c038

docs/git-resolver.md

@@ -155,7 +155,7 @@ spec:
 ```
 
 ## `ResolutionRequest` Status
-`ResolutionRequest.Status.Source` field captures the source where the remote resource came from. It includes the 3 subfields: `url`, `digest` and `entrypoint`.
+`ResolutionRequest.Status.RefSource` field captures the source where the remote resource came from. It includes the 3 subfields: `url`, `digest` and `entrypoint`.
 - `url`
   - If users choose to use anonymous cloning, the url is just user-provided value for the `url` param in the [SPDX download format](https://spdx.github.io/spdx-spec/package-information/#77-package-download-location-field). 
   - If scm api is used, it would be the clone URL of the repo fetched from scm repository service in the [SPDX download format](https://spdx.github.io/spdx-spec/package-information/#77-package-download-location-field). 
@@ -195,7 +195,7 @@ spec:
     revision: main
     url: https://github.com/<username>/<reponame>.git
 status:
-  source:
+  refSource:
     uri: git+https://github.com/<username>/<reponame>.git
     digest:
       sha1: <The latest commit sha on main at the moment of resolving>

docs/how-to-write-a-resolver.md

@@ -267,23 +267,23 @@ func (*myResolvedResource) Annotations() map[string]string {
   return nil
 }
 
-// Source is the source reference of the remote data that records where the remote 
+// RefSource is the source reference of the remote data that records where the remote 
 // file came from including the url, digest and the entrypoint. None atm.
-func (*myResolvedResource) Source() *pipelinev1beta1.ConfigSource {
+func (*myResolvedResource) RefSource() *pipelinev1beta1.RefSource {
 	return nil
 }
 ```
 
 Best practice: In order to enable Tekton Chains to record the source 
 information of the remote data in the SLSA provenance, the resolver should 
-implement the `Source()` method to return a correct ConfigSource value. See the 
+implement the `RefSource()` method to return a correct RefSource value. See the 
 following example.
 
 ```go
-// Source is the source reference of the remote data that records where the remote 
+// RefSource is the source reference of the remote data that records where the remote 
 // file came from including the url, digest and the entrypoint.
-func (*myResolvedResource) Source() *pipelinev1beta1.ConfigSource {
-	return &v1alpha1.ConfigSource{
+func (*myResolvedResource) RefSource() *pipelinev1beta1.RefSource {
+	return &v1alpha1.RefSource{
 		URI: "https://github.com/user/example",
 		Digest: map[string]string{
 			"sha1": "example",

docs/resolver-template/cmd/demoresolver/main.go

@@ -93,8 +93,8 @@ func (*myResolvedResource) Annotations() map[string]string {
 	return nil
 }
 
-// Source is the source reference of the remote data that records where the remote
+// RefSource is the source reference of the remote data that records where the remote
 // file came from including the url, digest and the entrypoint. None atm.
-func (*myResolvedResource) Source() *pipelinev1beta1.ConfigSource {
+func (*myResolvedResource) RefSource() *pipelinev1beta1.RefSource {
 	return nil
 }

pkg/apis/pipeline/v1/provenance.go

@@ -15,37 +15,32 @@ package v1
 
 import "github.com/tektoncd/pipeline/pkg/apis/config"
 
-// Provenance contains some key authenticated metadata about how a software artifact was
-// built (what sources, what inputs/outputs, etc.). For now, it only contains the subfield
-// `ConfigSource` that identifies the source where a build config file came from.
-// In future, it can be expanded as needed to include more metadata about the build.
-// This field aims to be used to carry minimum amount of the authenticated metadata in *Run status
-// so that Tekton Chains can pick it up and record in the provenance it generates.
+// Provenance contains metadata about resources used in the TaskRun/PipelineRun
+// such as the source from where a remote build definition was fetched.
+// This field aims to carry minimum amoumt of metadata in *Run status so that
+// Tekton Chains can capture them in the provenance.
 type Provenance struct {
-	// ConfigSource identifies the source where a resource came from.
-	ConfigSource *ConfigSource `json:"configSource,omitempty"`
+	// RefSource identifies the source where a remote task/pipeline came from.
+	RefSource *RefSource `json:"refSource,omitempty"`
 
 	// FeatureFlags identifies the feature flags that were used during the task/pipeline run
 	FeatureFlags *config.FeatureFlags `json:"featureFlags,omitempty"`
 }
 
-// ConfigSource identifies the source where a resource came from.
-// This can include Git repositories, Task Bundles, file checksums, or other information
-// that allows users to identify where the resource came from and what version was used.
-type ConfigSource struct {
-	// URI indicates the identity of the source of the config.
-	// Definition: https://slsa.dev/provenance/v0.2#invocation.configSource.uri
+// RefSource contains the information that can uniquely identify where a remote
+// built definition came from i.e. Git repositories, Tekton Bundles in OCI registry
+// and hub.
+type RefSource struct {
+	// URI indicates the identity of the source of the build definition.
 	// Example: "https://github.com/tektoncd/catalog"
 	URI string `json:"uri,omitempty"`
 
 	// Digest is a collection of cryptographic digests for the contents of the artifact specified by URI.
-	// Definition: https://slsa.dev/provenance/v0.2#invocation.configSource.digest
 	// Example: {"sha1": "f99d13e554ffcb696dee719fa85b695cb5b0f428"}
 	Digest map[string]string `json:"digest,omitempty"`
 
 	// EntryPoint identifies the entry point into the build. This is often a path to a
-	// configuration file and/or a target label within that file.
-	// Definition: https://slsa.dev/provenance/v0.2#invocation.configSource.entryPoint
+	// build definition file and/or a target label within that file.
 	// Example: "task/git-clone/0.8/git-clone.yaml"
 	EntryPoint string `json:"entryPoint,omitempty"`
 }