使用无服务器式的 Jenkins X：探索Prow，Jenkins X Pipeline Operator和Tekton

就像静态Jenkins一样，一切都起始于向Git库的一次push操作。随后，一个webhook请求被发送至集群中。不同的是，并没有用来接收这些请求的Jenkins。相反，我们有Prow。它会做很多事情，但在webhook这个场景下，它的工作是接收请求并决定下一步该做什么。这些请求不仅限于push操作，还包含了我们可以通过pull request评论指定的斜杠命令（例如/approve）。

Prow由几个不同的组件组成（例如，Deck，Hook，Crier，Tide等等）。然而，我们并不会深入介绍各个组件的职责。此刻，最需要留意的重要事项是Prow是群集的入口。它接收所有的Git请求，包含产生于Git动作的（例如push）与产生于评论中斜杠命令的。

Prow在收到请求后可能会做很多事情。如果它来自Git注释中的命令，它可能会重新运行测试，合并拉取请求，分配人员或许多其他Git相关操作之一。如果webhook通知它已经进行了新的推送，它将向Jenkins X Pipeline Operator发送一个请求，该请求将确保运行与定义的管道相对应的构建。最后，Prow还向Git报告了构建的状态。

这些特征并不是Prow可能执行的唯一动作类型，但是现在，你可能得到了一般的Gist。Prow负责Git与集群内部流程之间的通信。

当Prow Hook收到来自Git webhook的请求时，它会将其转发给Jenkins X Pipeline Operator。Operator的职责是从库中取回用于初始化流程的jenkins-x.yml文件，并将其转换为Tekton Tasks和Pipelines。反过来，它们定义了将变更push到Git后，应该被执行的完整流水线。

Pipeline Operator存在的原因是为了简化我们持续交付流程的定义。Tekton完成了繁重的工作，但这是一个非常低级的解决方案。它不应该直接使用。编写Tekton定义可能非常痛苦和复杂。Pipeline Operator通过易于学习和使用YAML格式来定义管道简化了这一过程。

Tekton为每次推送创建一个PipelineRun，每次推送都发送到一个相关的分支（例如，master分支，PR等），同时执行验证推送所需的所有步骤。Tekton运行测试，在注册表中存储二进制文件（例如，Docker Registry，Nexus和ChartMuseum），并将发布部署到临时（PR）或永久（临时或生产）环境。

完整的流程如下图所示：

正如上面已经提到的，并非每个人都需要了解事件的流程，也不需要深入了解流程中涉及的所有组件。对于大多数用户来说，唯一需要理解的是，将更改推送到Git将导致执行jenkins-x.yml管道中定义的构建。这就是Jenkins X的美丽。它通过简化复杂的过程简化了我们的生活。