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 Design for triggering PipelineRuns from events #315)

Actual Behavior

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

pipeline/pkg/apis/pipeline/v1alpha1/taskrun_types.go

Lines 95 to 115 in 19bf18a

	// TaskTriggerType indicates the mechanism by which this TaskRun was created.
	type TaskTriggerType string
	const (
	// TaskTriggerTypeManual indicates that this TaskRun was invoked manually by a user.
	TaskTriggerTypeManual TaskTriggerType = "manual"
	// TaskTriggerTypePipelineRun indicates that this TaskRun was created by a controller
	// attempting to realize a PipelineRun. In this case the `name` will refer to the name
	// of the PipelineRun.
	TaskTriggerTypePipelineRun TaskTriggerType = "pipelineRun"
	)
	// TaskTrigger describes what triggered this Task to run. It could be triggered manually,
	// or it may have been part of a PipelineRun in which case this ref would refer
	// to the corresponding PipelineRun.
	type TaskTrigger struct {
	Type TaskTriggerType `json:"type"`
	// +optional
	Name string `json:"name,omitempty,omitempty"`
	}

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!