Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Add Provenance field in TaskRun&PipelineRun status #5580

Merged
merged 1 commit into from
Oct 18, 2022
Merged

Add Provenance field in TaskRun&PipelineRun status #5580

merged 1 commit into from
Oct 18, 2022

Conversation

chuangw6
Copy link
Member

@chuangw6 chuangw6 commented Sep 28, 2022 •
edited
Loading

Changes

/kind feature

resolve #5550

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. This is an additive change, and this new field
is not populated with values or used anywhere yet in this PR.

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 so that
the Provenance struct can reuse the ConfigSource type (Otherwise, we cannot import it from
the api/resolution alpha because of the import cycle).

Why: See the motivation and discussions in #5550.
The tl;dr is that it helps pass provenance-related data in a more structured way
ConfigSource is one example.

Related PRs

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

Submitter Checklist

As the author of this PR, please check off the items in this checklist:

  • Has Docs included if any changes are user facing
  • Has Tests included if any functionality added or changed
  • Follows the commit message standard
  • Meets the Tekton contributor standards (including
    functionality, content, code)
  • Has a kind label. You can add one by adding a comment on this PR that contains /kind <type>. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep
  • Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings)
  • Release notes contains the string "action required" if the change requires additional action from users switching to the new release

Release Notes

Add Provenance field in TaskRun&PipelineRun status that wraps all the information we might need from pipeline side.

It only contains ConfigSource at the moment, but it can be extended to have more subfields in future.

@tekton-robot
Copy link
Collaborator

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

@tekton-robot tekton-robot added do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. do-not-merge/release-note-label-needed Indicates that a PR should not merge because it's missing one of the release note labels. labels Sep 28, 2022
@tekton-robot tekton-robot added size/L Denotes a PR that changes 100-499 lines, ignoring generated files. release-note Denotes a PR that will be considered when it comes time to generate release notes. and removed do-not-merge/release-note-label-needed Indicates that a PR should not merge because it's missing one of the release note labels. labels Sep 28, 2022
@tekton-robot tekton-robot added size/XL Denotes a PR that changes 500-999 lines, ignoring generated files. and removed size/L Denotes a PR that changes 100-499 lines, ignoring generated files. labels Oct 3, 2022
@chuangw6 chuangw6 marked this pull request as ready for review October 3, 2022 16:06
@chuangw6
Copy link
Member Author

chuangw6 commented Oct 3, 2022

/test check-pr-has-kind-label

@tekton-robot
Copy link
Collaborator

@chuangw6: The specified target(s) for /test were not found.
The following commands are available to trigger required jobs:

  • /test pull-tekton-pipeline-alpha-integration-tests
  • /test pull-tekton-pipeline-build-tests
  • /test pull-tekton-pipeline-integration-tests
  • /test tekton-pipeline-unit-tests

The following commands are available to trigger optional jobs:

  • /test pull-tekton-pipeline-go-coverage

Use /test all to run all jobs.

In response to this:

/test check-pr-has-kind-label

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.

@chuangw6
Copy link
Member Author

chuangw6 commented Oct 3, 2022

/kind feature

@tekton-robot tekton-robot added the kind/feature Categorizes issue or PR as related to a new feature. label Oct 3, 2022
@chuangw6 chuangw6 changed the title WIP: Add Provenance field in TaskRun&PipelineRun status Add Provenance field in TaskRun&PipelineRun status Oct 3, 2022
@tekton-robot tekton-robot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Oct 3, 2022
@chuangw6
Copy link
Member Author

chuangw6 commented Oct 3, 2022

Hey @abayer ,
FYI: I am moving the forked ConfigSource type from api/resolution to api/pipeline so that we can reuse that type in the Provenance struct. (Otherwise there will be import cycle issue.) Thanks!

@chuangw6
Copy link
Member Author

chuangw6 commented Oct 3, 2022

Please take a look @dibyom @wlynch

cc @jagathprakash @ywluogg. Thank you!

@abayer
Copy link
Contributor

abayer commented Oct 3, 2022

Thanks for letting me know, @chuangw6 - if this gets in before #5515 (which is likely), I'll update my PR accordingly!

@chuangw6 chuangw6 mentioned this pull request Oct 3, 2022
Merged
7 tasks
@abayer
Copy link
Contributor

abayer commented Oct 4, 2022

/approve

@tekton-robot tekton-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Oct 4, 2022
@tekton-robot tekton-robot merged commit 3f46fbb into tektoncd:main Oct 18, 2022
@JeromeJu JeromeJu mentioned this pull request Oct 20, 2022
Merged
7 tasks
chuangw6 added a commit to chuangw6/pipeline that referenced this pull request Oct 20, 2022
@chuangw6
Feature flag for provenance field in status
ed0f2eb 
Introduced a dedicated feature flag of boolean type named "enable-provenance-in-status"
in feature-flags configmap to enable the provenance field in status. The `provenance` field was introducted to *run status
in tektoncd#5580 status to record authenticated metadata about how a software artifact
was built i.e. the source where remote resource came from.

By default, this feature flag is false.

Signed-off-by: Chuang Wang <chuangw@google.com>
chuangw6 added a commit to chuangw6/pipeline that referenced this pull request Oct 20, 2022
@chuangw6
Feature flag for provenance field in status
267f1a4 
Introduced a dedicated feature flag of boolean type named "enable-provenance-in-status"
in feature-flags configmap to enable the provenance field in status. The `provenance` field was introducted to *run status
in tektoncd#5580 status to record authenticated metadata about how a software artifact
was built i.e. the source where remote resource came from.

By default, this feature flag is false.

Signed-off-by: Chuang Wang <chuangw@google.com>
chuangw6 added a commit to chuangw6/pipeline that referenced this pull request Oct 21, 2022
@chuangw6
Feature flag for provenance field in status
20f6bee 
Introduced a dedicated feature flag of boolean type named "enable-provenance-in-status"
in feature-flags configmap to enable the provenance field in status. The `provenance` field was introducted to *run status
in tektoncd#5580 status to record authenticated metadata about how a software artifact
was built i.e. the source where remote resource came from.

By default, this feature flag is false.

Signed-off-by: Chuang Wang <chuangw@google.com>
chuangw6 added a commit to chuangw6/pipeline that referenced this pull request Oct 21, 2022
@chuangw6
Feature flag for provenance field in status
7a816b7 
Introduced a dedicated feature flag of boolean type named "enable-provenance-in-status"
in feature-flags configmap to enable the provenance field in status. The `provenance` field was introducted to *run status
in tektoncd#5580 status to record authenticated metadata about how a software artifact
was built i.e. the source where remote resource came from.

By default, this feature flag is false.

Signed-off-by: Chuang Wang <chuangw@google.com>
chuangw6 added a commit to chuangw6/pipeline that referenced this pull request Oct 24, 2022
@chuangw6
Populate *Run.Status.Provenance.ConfigSource field
8a97e5e 
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 <chuangw@google.com>
chuangw6 added a commit to chuangw6/pipeline that referenced this pull request Oct 24, 2022
@chuangw6
Populate the *Run.Status.Provenance.ConfigSource field
70b071e 
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 <chuangw@google.com>
chuangw6 added a commit to chuangw6/pipeline that referenced this pull request Oct 24, 2022
@chuangw6
Populate the *Run.Status.Provenance.ConfigSource field
074210d 
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>
chuangw6 added a commit to chuangw6/pipeline that referenced this pull request Oct 27, 2022
@chuangw6
Populate the *Run.Status.Provenance.ConfigSource field
cda40d5 
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>
chuangw6 added a commit to chuangw6/pipeline that referenced this pull request Oct 27, 2022
@chuangw6
Populate the *Run.Status.Provenance.ConfigSource field
27f7d0d 
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>
chuangw6 added a commit to chuangw6/pipeline that referenced this pull request Nov 2, 2022
@chuangw6
Feature flag for provenance field in status
3e0ba90 
Introduced a dedicated feature flag of boolean type named "enable-provenance-in-status"
in feature-flags configmap to enable the provenance field in status. The `provenance` field was introducted to *run status
in tektoncd#5580 status to record authenticated metadata about how a software artifact
was built i.e. the source where remote resource came from.

By default, this feature flag is false.

Signed-off-by: Chuang Wang <chuangw@google.com>
chuangw6 added a commit to chuangw6/pipeline that referenced this pull request Nov 2, 2022
@chuangw6
Feature flag for provenance field in status
3d1bd8f 
Introduced a dedicated feature flag of boolean type named "enable-provenance-in-status"
in feature-flags configmap to enable the provenance field in status. The `provenance` field was introducted to *run status
in tektoncd#5580 status to record authenticated metadata about how a software artifact
was built i.e. the source where remote resource came from.

By default, this feature flag is false.

Signed-off-by: Chuang Wang <chuangw@google.com>
chuangw6 added a commit to chuangw6/pipeline that referenced this pull request Nov 2, 2022
@chuangw6
Feature flag for provenance field in status
eb31779 
Introduced a dedicated feature flag of boolean type named "enable-provenance-in-status"
in feature-flags configmap to enable the provenance field in status. The `provenance` field was introducted to *run status
in tektoncd#5580 status to record authenticated metadata about how a software artifact
was built i.e. the source where remote resource came from.

By default, this feature flag is false.

Signed-off-by: Chuang Wang <chuangw@google.com>
chuangw6 added a commit to chuangw6/pipeline that referenced this pull request Nov 2, 2022
@chuangw6
Feature flag for provenance field in status
feca8f2 
Introduced a dedicated feature flag of boolean type named "enable-provenance-in-status"
in feature-flags configmap to enable the provenance field in status. The `provenance` field was introducted to *run status
in tektoncd#5580 status to record authenticated metadata about how a software artifact
was built i.e. the source where remote resource came from.

By default, this feature flag is false.

Signed-off-by: Chuang Wang <chuangw@google.com>
chuangw6 added a commit to chuangw6/pipeline that referenced this pull request Nov 3, 2022
@chuangw6
Feature flag for provenance field in status
b39efbc 
Introduced a dedicated feature flag of boolean type named "enable-provenance-in-status"
in feature-flags configmap to enable the provenance field in status. The `provenance` field was introducted to *run status
in tektoncd#5580 status to record authenticated metadata about how a software artifact
was built i.e. the source where remote resource came from.

By default, this feature flag is false.

Signed-off-by: Chuang Wang <chuangw@google.com>
chuangw6 added a commit to chuangw6/pipeline that referenced this pull request Nov 3, 2022
@chuangw6
Feature flag for provenance field in status
7b870d1 
Introduced a dedicated feature flag of boolean type named "enable-provenance-in-status"
in feature-flags configmap to enable the provenance field in status. The `provenance` field was introducted to *run status
in tektoncd#5580 status to record authenticated metadata about how a software artifact
was built i.e. the source where remote resource came from.

By default, this feature flag is false.

Signed-off-by: Chuang Wang <chuangw@google.com>
chuangw6 added a commit to chuangw6/pipeline that referenced this pull request Nov 4, 2022
@chuangw6
Populate the *Run.Status.Provenance.ConfigSource field
f84e9a5 
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>
tekton-robot pushed a commit that referenced this pull request Nov 7, 2022
@chuangw6 @tekton-robot
Feature flag for provenance field in status
c2d0283 
Introduced a dedicated feature flag of boolean type named "enable-provenance-in-status"
in feature-flags configmap to enable the provenance field in status. The `provenance` field was introducted to *run status
in #5580 status to record authenticated metadata about how a software artifact
was built i.e. the source where remote resource came from.

By default, this feature flag is false.

Signed-off-by: Chuang Wang <chuangw@google.com>
chuangw6 added a commit to chuangw6/pipeline that referenced this pull request Nov 7, 2022
@chuangw6
Populate the *Run.Status.Provenance.ConfigSource field
98ab372 
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>
chuangw6 added a commit to chuangw6/pipeline that referenced this pull request Nov 7, 2022
@chuangw6
Populate the *Run.Status.Provenance.ConfigSource field
39ce674 
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>
chuangw6 added a commit to chuangw6/pipeline that referenced this pull request Nov 7, 2022
@chuangw6
Populate the *Run.Status.Provenance.ConfigSource field
64ed534 
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>
chuangw6 added a commit to chuangw6/pipeline that referenced this pull request Nov 8, 2022
@chuangw6
Feature flag for provenance field in status
045459c 
Introduced a dedicated feature flag of boolean type named "enable-provenance-in-status"
in feature-flags configmap to enable the provenance field in status. The `provenance` field was introducted to *run status
in tektoncd#5580 status to record authenticated metadata about how a software artifact
was built i.e. the source where remote resource came from.

By default, this feature flag is false.

Signed-off-by: Chuang Wang <chuangw@google.com>
chuangw6 added a commit to chuangw6/pipeline that referenced this pull request Nov 8, 2022
@chuangw6
Populate the *Run.Status.Provenance.ConfigSource field
985fb9c 
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>
chuangw6 added a commit to chuangw6/pipeline that referenced this pull request Nov 10, 2022
@chuangw6
Populate the *Run.Status.Provenance.ConfigSource field
135c6ac 
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>
chuangw6 added a commit to chuangw6/pipeline that referenced this pull request Nov 10, 2022
@chuangw6
Populate the *Run.Status.Provenance.ConfigSource field
741924b 
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>
chuangw6 added a commit to chuangw6/pipeline that referenced this pull request Nov 10, 2022
@chuangw6
Populate the *Run.Status.Provenance.ConfigSource field
00f1d32 
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>
chuangw6 added a commit to chuangw6/pipeline that referenced this pull request Nov 10, 2022
@chuangw6
Populate the *Run.Status.Provenance.ConfigSource field
55744ed 
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>
tekton-robot pushed a commit that referenced this pull request Nov 11, 2022
@chuangw6 @tekton-robot
Populate the *Run.Status.Provenance.ConfigSource field
ca7c70c 
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 <chuangw@google.com>
@chuangw6 chuangw6 mentioned this pull request Nov 16, 2022
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@Yongxuanzhang Yongxuanzhang Yongxuanzhang left review comments

@XinruZhang XinruZhang XinruZhang left review comments

@jagathprakash jagathprakash jagathprakash left review comments

@dibyom dibyom dibyom approved these changes

@wlynch wlynch wlynch approved these changes

Assignees

@wlynch wlynch

@XinruZhang XinruZhang

Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. kind/feature Categorizes issue or PR as related to a new feature. lgtm Indicates that a PR is ready to be merged. release-note Denotes a PR that will be considered when it comes time to generate release notes. size/XL Denotes a PR that changes 500-999 lines, ignoring generated files.
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

Add provenance-related data field in Run.Status
8 participants
@chuangw6 @tekton-robot @abayer @XinruZhang @jagathprakash @wlynch @dibyom @Yongxuanzhang