#介绍

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

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

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

#Overview

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

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

#Results 的生命周期

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

#数据模型

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

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