Refactor TaskRun / PipelineRun component trees to separate definitions from runtime data

[AlanGreene]

Changes

#885

Update the data processing done by the TaskRun/PipelineRun containers and their component
trees to separate the Task definitions from the TaskRun runtime data instead of using
our many custom representations that combined the two in different ways depending on need.

This should help to resolve confusion around the origin of a number of fields used in the
code, make it easier to maintain in future / easier for new contributors to understand,
and also allows for additional functionality that was cumbersome or essentially impossible
to achieve before.

Since we're no longer bound by the definitions to construct the bulk of the UI, we can
now more easily display generated steps for PipelineResources etc. giving a more complete
representation of the run.

The following issues should benefit from this change, making them easier to address:

• Update TaskTree design #1775
• When a PipelineRun is in progress ensure the TaskTree renders the full set of Tasks #1263

Also resolves #572

Submitter Checklist

These are the criteria that every PR should meet, please check them off as you
review them:

• Includes tests (if functionality changed/added)
• Includes docs (if user facing)
• Commit messages follow commit message best practices

See the contribution guide
for more details.

[AlanGreene]

/retest

[AlanGreene]

Had a call + screen share with Steve earlier to walk through the major changes and discuss additional scenarios to test. So far I'm not seeing any new issues. 🤞

[steveodonovan]

Code wise this looks good to me but there are a couple of more things to throw at this,

https://github.com/tektoncd/pipeline/blob/master/pkg/reconciler/pipelinerun/pipelinerun.go#L64

Would be worth double checking we handle these states gracefully ?

[AlanGreene]

Checking:

• CouldntGetCondition
• CouldntGetPipeline
• CouldntGetResource
• CouldntGetTask
• InvalidPipelineResourceBindings
• InvalidServiceAccountMappings
• InvalidTaskResultReference
• InvalidWorkspaceBindings
• ParameterMissing
• ParameterTypeMismatch
• PipelineInvalidGraph
• PipelineRunCancelled
• PipelineRunCouldntCancel
• PipelineValidationFailed

Update:

All but 2 of these error cases are handled the same as before this change, displaying the RunHeader with details of the error message.

I couldn't find a way to trigger PipelineInvalidGraph. By introducing a cycle as described in the code comment it's actually rejected by the admission webhook:

Error from server (BadRequest): error when creating "test.yaml": admission webhook "validation.webhook.pipeline.tekton.dev" denied the request: validation failed: invalid value: couldn't add link between a-task and another-task: couldn't create link from another-task to a-task: cycle detected: a-task -> another-task -> a-task: spec.tasks

I also couldn't reproduce InvalidTaskResultReference, instead getting PipelineValidationFailed if I try to reference a result that doesn't exist, or no error if declaring a result that's not produced by the task.

[steveodonovan]

/approve
/lgtm

[tekton-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: steveodonovan

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [steveodonovan]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment