Pipeline: Design: Track provenance of TaskRuns and PipelineRuns

[bobcatfish]

Expected Behavior

It should be possible to look at the data contained in a TaskRun or a PipelineRun and determine what led to the creation of this Run, for example:

• If the Run was created manually
• If the TaskRun was created to fulfill a PipelineRun
• If the PipelineRun was created in response to some event (not functionality that we have yet, see #315)

Actual Behavior

We have a field called trigger which is being used for this purpose:

https://github.com/tektoncd/pipeline/blob/19bf18abe2f7e71c5eb3ee6ff10351643db5510b/pkg/apis/pipeline/v1alpha1/taskrun_types.go#L95-L115

But as seen in #816:

• this confuses people
• it might make sense to use annotations instead

Additional Info

See also the pipeline listener proposal

[abayer]

For TaskRun, we can tell if it was created via a PipelineRun by looking at the labels currently.

[dlorenc]

I agree that the field here is confusing. I think in general annotations/labels would make more sense for this type of data.

[kimholmes]

This also looks like something that could be accomplished in the dashboard UI.

[vdemeester]

@bobcatfish I feel this issue should be either closed or rewritten. The trigger field is gone, now the way to know what started a taskrun or pipelinerun would be "achieved" using some standard annotation/labels, that could be set by the cli, triggers or any other tool.

I think we should document those, and define some best practice

[tekton-robot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.

/lifecycle stale

Send feedback to tektoncd/plumbing.

[bobcatfish]

I think closing this makes sense until we have a clear need for it and we can come up with some options - probably annotations is the way to go!