[EPIC] Pipeline CRD results are stored to a Result Store via Result Store API

[tejal29]

Expected Behavior

Results for Tasks and Pipeline Runs are stored and available later.

Structured Result Stores are places to upload the results of each Knative Build.
A Knative Build can be a result of TaskRun. The TaskRun Controller will be responsible to upload, update and fetch the results for a Build to and from the Result Store.

Types of Results

In Pipeline CRD, results will be produced by a

• TaskRun and
• PipelineRun.

Structured Result Store API Requirements

Required Requirements

• Upload to the result stores
• A task should be able to upload to result store for every result produced during its execution
• Download a specific Result.
  API should support downloading a specific Result.
• Update a result in a result store.
• For complex multi-task pipeline we would want to update the
  PipelineRunResult as TaskRuns complete. This will prevent Controllers from holding onto too much state for a Pipeline.

Additional Requirements

• List results for a given TaskRun.
• Structured Result Store API should be able to provide a list of results produced during a task run.
• Download StepLog for a specific step in a Task Run.
• Each Step in a TaskRun is container run. The KBuild container run logs should be mapped to each step. That way, we can effectively stream logs to the presentation layer.
  For this, we will have to work with BuildCrd group.
• Support different types of Result.
• PipelineCRD itself defines resources. Some of the resources like Image themselves can be results of Tasks. Other examples are Junit-test results, Binary Blob.
• The API, can support querying different ResultType.

Actual Behavior

Right now, the logs and results for a pipeline and task runs are available in cluster as Pod Run State.
These get garbage collected as pods get deleted.
Result Store aims to provide persistence storage for all the logs and run state for pipeline and tasks.

[bobcatfish]

I think this issue has more info than #454 but we seem to have moved our work over to #454 so I'm going to close this.