#介绍

Tekton Results 旨在帮助用户逻辑上对 CI/CD 工作负载的历史记录进行分组，并将长期 Results 存储与 Pipeline controller 分离。这样您可以：

• 提供有关 CI/CD 工作流的自定义 Results 元数据，这些信息在 Tekton TaskRun/PipelineRun CRDs 中不可用（例如，post-run actions）
• 将相关工作负载分组在一起（例如，将相关的 TaskRuns 和 PipelineRuns 捆绑为一个单元）
• 使长期 Results 历史独立于 Pipeline CRD controller，从而释放用于运行执行的 etcd 资源。
• 存储由 TaskRun/PipelineRun 生成的日志，以便清理已完成的运行来节省资源。

更多背景和设计动机请参见 TEP-0021。

#概述

Tekton Results 由两个主要组件组成：

• 一个可通过 API 查询的 gRPC API server，由持久化存储提供支持（有关最新 API 规范，请参见 proto/v1alpha2 中的项目源代码）。
• 一个 watcher controller，用于监控 TaskRuns 和 PipelineRuns 的更新并将其报告给 API server。

#Results 的生命周期

1. 用户像往常一样通过 Kubernetes API 创建 TaskRuns 或 PipelineRuns。
2. Results Watcher 监听所有 TaskRuns/PipelineRuns 的变更。
3. 如果 TaskRun/PipelineRun 发生变化，watcher 会使用 Results API 更新（或创建）对应的 Record（如果需要，也会创建一个 Result）。
   • watcher 还会使用一个标识符为原始 TaskRun/PipelineRun 添加注解。
4. 用户可以直接从 API 获取/查询 Results/Records 数据。一旦 TaskRun/PipelineRun 完成并成功存储到 Results API，原始 CRD 对象就可以安全地从集群中删除。

#数据模型

• record 是一条数据的单个实例。它们通常是执行数据（例如，PipelineRun、TaskRun、logs），但也可能引用有关事件/执行的其他数据。Records 的设计旨在灵活支持工具希望提供的任何有关 CI 事件的信息。
• Results 是 records 的聚合器，允许用户将一组 records 作为单个实体来引用。例如，您可能有一个 Results，用于分组以下 records：
  • 触发操作的源事件（例如，pull request、push）。
  • 创建的 PipelineRun。
  • 为响应 PipelineRun 而创建的 TaskRuns。
  • cloud events 的接收。
  • source status updates 的接收。

（注意：watcher 目前不支持所有这些类型的数据，但它们是我们打算支持的数据示例。）