#Introduction

Tekton Results is designed to help users logically group the historical records of CI/CD workloads and separate long-term Results storage from the Pipeline controller. This allows you to:

• Provide custom Results metadata about CI/CD workflows that are not available in Tekton TaskRun/PipelineRun CRDs (e.g., post-run actions)
• Group related workloads together (e.g., bundling related TaskRuns and PipelineRuns into a single unit)
• Make long-term Results history independent of the Pipeline CRD controller, thereby freeing etcd resources for run executions.
• Store logs generated by TaskRun/PipelineRun so that completed runs can be cleaned up to save resources.

Additional background and design motivation can be found in TEP-0021.

#Overview

Tekton Results consists of two main components:

• An API-queriable gRPC API server backed by persistent storage (see the project source code in proto/v1alpha2 for the latest API specifications).
• A watcher controller used to monitor and report updates of TaskRuns and PipelineRuns to the API server.

#Lifecycle of Results

1. Users create TaskRuns or PipelineRuns through the Kubernetes API as usual.
2. The Results Watcher listens for changes to all TaskRuns/PipelineRuns.
3. If a TaskRun/PipelineRun changes, the watcher updates (or creates) the corresponding Record using the Results API (it will also create a Result if needed).
   • The watcher also annotates the original TaskRun/PipelineRun with an identifier.
4. Users can directly fetch/query Results/Records data from the API. Once the TaskRun/PipelineRun completes and is successfully stored in the Results API, the original CRD objects can be safely deleted from the cluster.

#Data Model

• A record is a single instance of data. These are typically execution data (e.g., PipelineRun, TaskRun, logs) but may also reference other data about events/executions. Records are designed to flexibly support any information that tools wish to provide about CI events.
• Results are aggregators of records, allowing users to reference groups of records as a single entity. For example, you might have a Results grouping the following records:
  • The source event that triggered the operation (e.g., a pull request, a push).
  • The created PipelineRun.
  • The TaskRuns created in response to the PipelineRun.
  • The receipt of cloud events.
  • The receipt of source status updates.

(Note: The watcher currently does not support all these types of data, but they are examples of the data we intend to support.)