4.2. 了解 OpenShift Pipelines

Red Hat OpenShift Pipelines 是一个基于 Kubernetes 资源的云原生的持续集成和持续交付（continuous integration and continuous delivery，简称 CI/CD）的解决方案。它通过提取底层实现的详情，使用 Tekton 构建块进行跨多个平台的自动部署。Tekton 引入了多个标准自定义资源定义 (CRD)，用于定义可跨 Kubernetes 分布的 CI/CD 管道。

4.2.1. 主要特性

Red Hat OpenShift Pipelines 是一个无服务器的 CI/CD 系统，它在独立的容器中运行 Pipelines，以及所有需要的依赖组件。
Red Hat OpenShift Pipelines 是为开发基于微服务架构的非中心化团队设计的。
Red Hat OpenShift Pipelines 使用标准 CI/CD 管道（pipeline）定义，这些定义可轻松扩展并与现有 Kubernetes 工具集成，可让您按需扩展。
您可以通过 Red Hat OpenShift Pipelines 使用 Kubernetes 工具（如 Source-to-Image (S2I)、Buildah、Buildpacks 和 Kaniko）构建镜像，这些工具可移植到任何 Kubernetes 平台。
您可以使用 OpenShift Container Platform 开发控制台来创建 Tekton 资源，查看管道运行的日志，并管理 OpenShift Container Platform 命名空间中的管道。

4.2.2. OpenShift Pipeline 概念

本指南提供了对管道（pipeline）概念的详细论述。

4.2.2.1. 任务

Task（任务）是 Pipeline 的构建块，它由按顺序执行的步骤组成。它基本上是一个输入和输出的功能。一个任务可以单独运行，也可以作为管道的一部分运行。任务（Task）可以重复使用，并可用于多个 Pipelines。

Step（步骤）是由任务顺序执行并实现特定目标（如构建镜像）的一系列命令。每个任务都作为 pod 运行，每个步骤都作为该 pod 中的容器运行。由于步骤在同一个 pod 中运行，所以它们可以访问同一卷来缓存文件、配置映射和 secret。

以下示例显示了 apply-manifests 任务。

apiVersion: tekton.dev/v1beta1 1
kind: Task 2
metadata:
  name: apply-manifests 3
spec: 4
  workspaces:
  - name: source
  params:
    - name: manifest_dir
      description: The directory in source that contains yaml manifests
      type: string
      default: "k8s"
  steps:
    - name: apply
      image: image-registry.openshift-image-registry.svc:5000/openshift/cli:latest
      workingDir: /workspace/source
      command: ["/bin/bash", "-c"]
      args:
        - |-
          echo Applying manifests in $(params.manifest_dir) directory
          oc apply -f $(params.manifest_dir)
          echo -----------------------------------

1: Task API 版本 v1beta1。
2: Kubernetes 对象的类型，任务。
3: 此任务的唯一名称。
4: 列出任务中的参数和步骤，以及任务使用的工作区（workspace）。

此任务启动 pod，并在该 pod 中使用指定镜像运行一个容器，以运行指定的命令。

4.2.2.2. When 表达式

When 表达式通过设置管道中执行任务的条件来执行任务。它们包含一个组件列表，允许仅在满足特定条件时执行任务。当使用管道 YAML 文件中的 finally 字段指定的最终任务集合中也支持表达式。

表达式的主要组件如下：

input：指定静态输入或变量，如参数、任务结果和执行状态。您必须输入有效的输入。如果没有输入有效输入，则其值默认为空字符串。
operator：指定一个输入与一组 values 的关系。输入 in 或 notin 作为 operator 的值。
values：指定字符串值的数组。输入由静态值或变量组成的非空数组，如参数、结果和工作空间的绑定状态。

在任务运行前评估表达式时声明的。如果 when 表达式的值为 True，则任务将运行。如果 when 表达式的值为 False，则跳过任务。

您可以在各种用例中使用 when 表达式。例如，是否：

上一任务的结果如预期所示。
之前的提交中更改了 Git 存储库中的文件。
镜像是否存在于 registry 中。
有可选的工作区可用。

以下示例显示了管道运行的 when 表达式。只有在满足以下条件时，管道运行才会执行 create-file 任务：path 参数为README.md，只有来自 check-file 的任务的 exists 结果为 yes 时才执行 echo-file-exists 任务。

apiVersion: tekton.dev/v1beta1
kind: PipelineRun 1
metadata:
  generateName: guarded-pr-
spec:
  serviceAccountName: 'pipeline'
  pipelineSpec:
    params:
      - name: path
        type: string
        description: The path of the file to be created
    workspaces:
      - name: source
        description: |
          This workspace is shared among all the pipeline tasks to read/write common resources
    tasks:
      - name: create-file 2
        when:
          - input: "$(params.path)"
            operator: in
            values: ["README.md"]
        workspaces:
          - name: source
            workspace: source
        taskSpec:
          workspaces:
            - name: source
              description: The workspace to create the readme file in
          steps:
            - name: write-new-stuff
              image: ubuntu
              script: 'touch $(workspaces.source.path)/README.md'
      - name: check-file
        params:
          - name: path
            value: "$(params.path)"
        workspaces:
          - name: source
            workspace: source
        runAfter:
          - create-file
        taskSpec:
          params:
            - name: path
          workspaces:
            - name: source
              description: The workspace to check for the file
          results:
            - name: exists
              description: indicates whether the file exists or is missing
          steps:
            - name: check-file
              image: alpine
              script: |
                if test -f $(workspaces.source.path)/$(params.path); then
                  printf yes | tee /tekton/results/exists
                else
                  printf no | tee /tekton/results/exists
                fi
      - name: echo-file-exists
        when: 3
          - input: "$(tasks.check-file.results.exists)"
            operator: in
            values: ["yes"]
        taskSpec:
          steps:
            - name: echo
              image: ubuntu
              script: 'echo file exists'
...
      - name: task-should-be-skipped-1
        when: 4
          - input: "$(params.path)"
            operator: notin
            values: ["README.md"]
        taskSpec:
          steps:
            - name: echo
              image: ubuntu
              script: exit 1
...
    finally:
      - name: finally-task-should-be-executed
        when: 5
          - input: "$(tasks.echo-file-exists.status)"
            operator: in
            values: ["Succeeded"]
          - input: "$(tasks.status)"
            operator: in
            values: ["Succeeded"]
          - input: "$(tasks.check-file.results.exists)"
            operator: in
            values: ["yes"]
          - input: "$(params.path)"
            operator: in
            values: ["README.md"]
        taskSpec:
          steps:
            - name: echo
              image: ubuntu
              script: 'echo finally done'
  params:
    - name: path
      value: README.md
  workspaces:
    - name: source
      volumeClaimTemplate:
        spec:
          accessModes:
            - ReadWriteOnce
          resources:
            requests:
              storage: 16Mi

1: 指定 Kubernetes 对象的类型。在本例中，PipelineRun。
2: Pipeline 中使用的任务 create-file。
3: when 表达式指定，只有来自 check-file 的 exists 结果为 yes 时才执行 echo-file-exists 任务。
4: when 表达式指定，只有 path 参数是 README.md 时跳过 task-should-be-skipped-1 任务。
5: when 表达式指定，只有 echo-file-exists 任务的执行状态以及任务状态为 Succeeded，来自 check-file 任务的 exists 结果为 yes，path 参数是 README.md 时，才执行 finally-task-should-be-executed 任务。

OpenShift Container Platform Web 控制台的 Pipeline Run details 页面显示任务和 when 表达式的状态，如下所示：

所有条件都满足：任务和 when 表达式符号（以钻石形表示）为绿色。
有任何一个条件不符合：任务被跳过。跳过的任务和 when 表达式符号为灰色。
未满足任何条件：任务被跳过。跳过的任务和 when 表达式符号为灰色。
任务运行失败：失败的任务和 when 表达式符号为红色。

4.2.2.3. 最后的任务

finally 任务是使用管道 YAML 文件中的 finally 字段指定的最终任务集合。finally 任务始终执行管道中的任务，无论管道运行是否成功执行。finally 任务以并行方式执行，在所有管道任务运行后，相应的频道存在前。

您可以配置一个 finally 任务，以使用同一管道中任何任务的结果。这个方法不会更改运行此最终任务的顺序。它在所有非最终任务执行后与其他最终任务并行执行。

以下示例显示了 clone-cleanup-workspace 管道的代码片段。此代码将存储库克隆到共享的工作区，并清理工作区。执行管道任务后，管道 YAML 文件的 finally 中指定的 cleanup 任务会清理工作区。

apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
  name: clone-cleanup-workspace 1
spec:
  workspaces:
    - name: git-source 2
  tasks:
    - name: clone-app-repo 3
      taskRef:
        name: git-clone-from-catalog
      params:
        - name: url
          value: https://github.com/tektoncd/community.git
        - name: subdirectory
          value: application
      workspaces:
        - name: output
          workspace: git-source
  finally:
    - name: cleanup 4
      taskRef: 5
        name: cleanup-workspace
      workspaces: 6
        - name: source
          workspace: git-source
    - name: check-git-commit
      params: 7
        - name: commit
          value: $(tasks.clone-app-repo.results.commit)
      taskSpec: 8
        params:
          - name: commit
        steps:
          - name: check-commit-initialized
            image: alpine
            script: |
              if [[ ! $(params.commit) ]]; then
                exit 1
              fi

1: Pipeline 的唯一名称。
2: 克隆 git 存储库的共享工作区。
3: 将应用存储库克隆到共享工作区的任务。
4: 清理共享工作区的任务。
5: 对 TaskRun 中要执行的任务的引用。
6: Pipeline 中的任务在运行时需要的共享存储卷来接收输入或提供输出。
7: 任务所需的参数列表。如果参数没有隐式默认值，您必须明确设置其值。
8: 嵌入式任务定义.

4.2.2.4. TaskRun

TaskRun 使用集群上的特定输入、输出和执行参数来实例化一个任务用来执行它。它可自行调用，或作为管道中每个任务的 PipelineRun 的一部分。

任务由执行容器镜像的一个或多个步骤组成，每个容器镜像执行特定的构建工作。TaskRun 以指定顺序在任务中执行步骤，直到所有步骤都成功执行或发生失败为止。PipelineRun 由 Pipeline 中每个任务的 PipelineRun 自动创建。

以下示例显示了一个带有相关输入参数运行 apply-manifests 任务的 TaskRun:

apiVersion: tekton.dev/v1beta1 1
kind: TaskRun 2
metadata:
  name: apply-manifests-taskrun 3
spec: 4
  serviceAccountName: pipeline
  taskRef: 5
    kind: Task
    name: apply-manifests
  workspaces: 6
  - name: source
    persistentVolumeClaim:
      claimName: source-pvc

1: TaskRun API 版本 v1beta1。
2: 指定 Kubernetes 对象的类型。在本例中，TaskRun。
3: 用于标识此 TaskRun 的唯一名称。
4: TaskRun 的定义。对于这个 TaskRun，指定了任务和所需的工作区。
5: 用于此 TaskRun 的任务引用的名称。此 TaskRun 会执行 apply-manifests 任务。
6: TaskRun 使用的工作空间。

4.2.2.5. Pipelines

Pipeline 一组 Task（任务）资源，它们按特定顺序执行。执行它们是为了构建复杂的工作流，以自动化应用程序的构建、部署和交付。您可以使用包含一个或多个任务的管道为应用程序定义 CI/CD 工作流。

Pipeline 资源的定义由多个字段或属性组成，它们一起可让管道实现一个特定目标。每个 Pipeline 资源定义必须至少包含一个Task（任务）资源，用于控制特定输入并生成特定的输出。Pipeline 定义也可以根据应用程序要求包括 Conditions、Workspaces、Parameters 或 Resources。

以下示例显示了 build-and-deploy pipeline，它使用 buildah ClusterTask 资源从 Git 存储库构建应用程序镜像：

apiVersion: tekton.dev/v1beta1 1
kind: Pipeline 2
metadata:
  name: build-and-deploy 3
spec: 4
  workspaces: 5
  - name: shared-workspace
  params: 6
  - name: deployment-name
    type: string
    description: name of the deployment to be patched
  - name: git-url
    type: string
    description: url of the git repo for the code of deployment
  - name: git-revision
    type: string
    description: revision to be used from repo of the code for deployment
    default: "pipelines-1.5"
  - name: IMAGE
    type: string
    description: image to be built from the code
  tasks: 7
  - name: fetch-repository
    taskRef:
      name: git-clone
      kind: ClusterTask
    workspaces:
    - name: output
      workspace: shared-workspace
    params:
    - name: url
      value: $(params.git-url)
    - name: subdirectory
      value: ""
    - name: deleteExisting
      value: "true"
    - name: revision
      value: $(params.git-revision)
  - name: build-image 8
    taskRef:
      name: buildah
      kind: ClusterTask
    params:
    - name: TLSVERIFY
      value: "false"
    - name: IMAGE
      value: $(params.IMAGE)
    workspaces:
    - name: source
      workspace: shared-workspace
    runAfter:
    - fetch-repository
  - name: apply-manifests 9
    taskRef:
      name: apply-manifests
    workspaces:
    - name: source
      workspace: shared-workspace
    runAfter: 10
    - build-image
  - name: update-deployment
    taskRef:
      name: update-deployment
    workspaces:
    - name: source
      workspace: shared-workspace
    params:
    - name: deployment
      value: $(params.deployment-name)
    - name: IMAGE
      value: $(params.IMAGE)
    runAfter:
    - apply-manifests

1: Pipeline API 版本 v1beta1。
2: 指定 Kubernetes 对象的类型。在本例中, Pipeline。
3: 此 Pipeline 的唯一名称。
4: 指定 Pipeline 的定义和结构。
5: Pipeline 中所有任务使用的工作区。
6: Pipeline 中所有任务使用的参数。
7: 指定 Pipeline 中使用的任务列表。
8: 任务 build-image 使用 buildah ClusterTask 从给定的 Git 仓库构建应用程序镜像。
9: 任务 apply-manifests 使用相同名称的用户定义的任务。
10: 指定在 Pipeline 中运行任务的顺序。在本例中，apply-manifests 任务仅在 build-image 任务完成后运行。

注意

Red Hat OpenShift Pipelines Operator 安装 Buildah 集群任务，并创建具有足够权限来构建和推送镜像的管道服务帐户。当与没有权限不足的不同服务帐户关联时，Buildah 集群任务可能会失败。

4.2.2.6. PipelineRun

PipelineRun 是一种资源类型，它绑定了管道、工作区、凭证和一组特定于运行 CI/CD 工作流的情况的参数值。

管道运行（pipeline run）是管道的运行实例。它使用集群上的特定输入、输出和执行参数来实例化 Pipeline 执行。它还为管道运行中的每个任务创建一个任务运行。

管道按顺序运行任务，直到任务完成或任务失败为止。status 字段跟踪和每个任务运行的进度，并存储它以用于监控和审计目的。

以下示例显示了一个 PipelineRun，用于运行带有相关资源和参数的 build-and-deploy Pipeline:

apiVersion: tekton.dev/v1beta1 1
kind: PipelineRun 2
metadata:
  name: build-deploy-api-pipelinerun 3
spec:
  pipelineRef:
    name: build-and-deploy 4
  params: 5
  - name: deployment-name
    value: vote-api
  - name: git-url
    value: https://github.com/openshift-pipelines/vote-api.git
  - name: IMAGE
    value: image-registry.openshift-image-registry.svc:5000/pipelines-tutorial/vote-api
  workspaces: 6
  - name: shared-workspace
    volumeClaimTemplate:
      spec:
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: 500Mi

1: Pipeline 运行 API 版本 v1beta1。
2: Kubernetes 对象的类型。在本例中，PipelineRun。
3: 用于标识此管道运行的唯一名称。
4: 要运行的管道的名称。在本例中，build-and-deploy。
5: 运行管道所需的参数列表。
6: 管道运行使用的工作区。

其他资源

使用 git secret 验证管道

4.2.2.7. Workspaces（工作区）

注意

建议您在 OpenShift Pipelines 中使用 Workspaces 而不是 PipelineResources，因为 PipelineResources 很难调试，范围有限，且不容易重复使用。

Workspace 声明 Pipeline 中的任务在运行时需要的共享存储卷来接收输入或提供输出。Workspaces 不指定卷的实际位置，它允许您定义运行时所需的文件系统或部分文件系统。Task 或 Pipeline 会声明 Workspace，您必须提供卷的特定位置详情。然后，它会挂载到 TaskRun 或 PipelineRun 中的 Workspace 中。这种将卷声明与运行时存储卷分开来使得任务可以被重复使用、灵活且独立于用户环境。

使用 Workspaces，您可以：

存储任务输入和输出
任务间共享数据
使用它作为 Secret 中持有的凭证的挂载点
使用它作为 ConfigMap 中保存的配置的挂载点
使用它作为机构共享的通用工具的挂载点
创建可加快作业的构建工件缓存

您可以使用以下方法在 TaskRun 或 PipelineRun 中指定 Workspaces:

只读 ConfigMap 或 Secret
与其他任务共享的现有 PersistentVolumeClaim
来自提供的 VolumeClaimTemplate 的 PersistentVolumeClaim
TaskRun 完成后丢弃的 emptyDir

以下显示了 build-and-deploy Pipeline 的代码片段，它为任务 build-image 和 apply-manifests 声明了一个 shared-workspace Workspace。

apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
  name: build-and-deploy
spec:
  workspaces: 1
  - name: shared-workspace
  params:
...
  tasks: 2
  - name: build-image
    taskRef:
      name: buildah
      kind: ClusterTask
    params:
    - name: TLSVERIFY
      value: "false"
    - name: IMAGE
      value: $(params.IMAGE)
    workspaces: 3
    - name: source 4
      workspace: shared-workspace 5
    runAfter:
    - fetch-repository
  - name: apply-manifests
    taskRef:
      name: apply-manifests
    workspaces: 6
    - name: source
      workspace: shared-workspace
    runAfter:
      - build-image
...

1: Pipeline 中定义的任务共享的 Workspace 列表。Pipeline 可以根据需要定义 Workspace。在这个示例中，只声明了一个名为 shared-workspace 的 Workspace。
2: Pipeline 中使用的任务定义。此片段定义了两个任务，build-image 和 apply-manifests。这两个任务共享一个 Workspace。
3: build-image 任务中使用的 Workspaces 列表。任务定义可以根据需要包含多个 Workspace。但建议任务最多使用一个可写 Workspace。
4: 唯一标识任务中使用的 Workspace 的名称。此任务使用一个名为 source 的 Workspace。
5: 任务使用的 Pipeline Workspace 的名称。请注意,，Workspace source 使用 Pipeline Workspace shared-workspace。
6: apply-manifests 任务中使用的 Workspace 列表。请注意，此任务与 build-image 任务共享 source Workspace。

工作区可帮助任务共享数据，并允许您指定 Pipeline 中每个任务在执行过程中所需的一个或多个卷。您可以创建持久性卷声明，或者提供一个卷声明模板，用于为您创建持久性卷声明。

以下 build-deploy-api-pipelinerun PipelineRun 的代码片段使用卷声明模板创建持久性卷声明来为 build-and-deploy Pipeline 中使用的 shared-workspace Workspace 定义存储卷。

apiVersion: tekton.dev/v1beta1
kind: PipelineRun
metadata:
  name: build-deploy-api-pipelinerun
spec:
  pipelineRef:
    name: build-and-deploy
  params:
...

  workspaces: 1
  - name: shared-workspace 2
    volumeClaimTemplate: 3
      spec:
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: 500Mi

1: 指定 Pipeline Workspaces 列表，用于在 PipelineRun 中提供卷绑定。
2: 提供卷的 Pipeline 中的 Workspace 的名称。
3: 指定卷声明模板，该模板可创建一个持久性卷声明来为工作区定义存储卷。

4.2.2.8. 触发器

使用触发器（Trigger）和 Pipelines 一起创建一个完整的 CI/CD 系统，其中 Kubernetes 资源定义整个 CI/CD 执行。触发器捕获外部事件，如 Git 拉取请求，并处理它们以获取关键信息。将这个事件数据映射到一组预定义的参数会触发一系列任务，然后创建和部署 Kubernetes 资源并实例化管道。

例如，您可以使用 Red Hat OpenShift Pipelines 为应用程序定义 CI/CD 工作流。管道必须启动，才能在应用程序存储库中使任何新的更改生效。通过捕获和处理任何更改事件，并通过触发器部署新镜像的管道运行来自动触发这个过程。

触发器由以下主要资源组成，它们可一起组成可重复使用、分离和自力更生的 CI/CD 系统：

TriggerBinding 资源从事件有效负载中提取字段，并将它们保存为参数。
以下示例显示了 TriggerBinding 资源的代码片段,它从接收的事件有效负载中提取 Git 存储库信息：
```
apiVersion: triggers.tekton.dev/v1alpha1 1
kind: TriggerBinding 2
metadata:
  name: vote-app 3
spec:
  params: 4
  - name: git-repo-url
    value: $(body.repository.url)
  - name: git-repo-name
    value: $(body.repository.name)
  - name: git-revision
    value: $(body.head_commit.id)
```
1
TriggerBinding 资源的 API 版本。在本例中，v1alpha1。
2
指定 Kubernetes 对象的类型。在本例中，TriggerBinding。
3
用于标识 TriggerBinding 资源的唯一名称。
4
从接收的事件有效负载中提取并传递给 TriggerTemplate 的参数列表。在本例中，Git 仓库 URL、名称和修订版本是从事件有效负载主体中提取的。

TriggerTemplate 资源充当创建资源的方式标准。它指定了 TriggerBinding 资源中参数化数据的方式。触发器模板从触发器绑定接收输入，然后执行一系列操作来创建新管道资源，并启动新管道运行。

以下示例显示了 TriggerTemplate 资源的代码片段，它使用您刚创建的 TriggerBinding 资源提供的 Git 存储库信息创建一个管道运行：

apiVersion: triggers.tekton.dev/v1alpha1 1
kind: TriggerTemplate 2
metadata:
  name: vote-app 3
spec:
  params: 4
  - name: git-repo-url
    description: The git repository url
  - name: git-revision
    description: The git revision
    default: pipelines-1.5
  - name: git-repo-name
    description: The name of the deployment to be created / patched

  resourcetemplates: 5
  - apiVersion: tekton.dev/v1beta1
    kind: PipelineRun
    metadata:
      name: build-deploy-$(tt.params.git-repo-name)-$(uid)
    spec:
      serviceAccountName: pipeline
      pipelineRef:
        name: build-and-deploy
      params:
      - name: deployment-name
        value: $(tt.params.git-repo-name)
      - name: git-url
        value: $(tt.params.git-repo-url)
      - name: git-revision
        value: $(tt.params.git-revision)
      - name: IMAGE
        value: image-registry.openshift-image-registry.svc:5000/pipelines-tutorial/$(tt.params.git-repo-name)
      workspaces:
      - name: shared-workspace
        volumeClaimTemplate:
         spec:
          accessModes:
           - ReadWriteOnce
          resources:
            requests:
              storage: 500Mi

1: TriggerTemplate 资源的 API 版本。在本例中，v1alpha1。
2: 指定 Kubernetes 对象的类型。在本例中，TriggerTemplate。
3: 用于标识 TriggerTemplate 资源的唯一名称。
4: TriggerBinding 资源提供的参数。
5: 指定使用 TriggerBinding 或 EventListener 资源接收的参数创建资源方法的模板列表。

Trigger 资源组合了 TriggerBinding 和 TriggerTemplate 资源，以及可选的 interceptors 事件处理器。
拦截器会处理在 TriggerBinding 资源之前运行的特定平台的所有事件。您可以使用拦截器过滤载荷，验证事件，定义和测试触发器条件，以及实施其他有用的处理。拦截器使用 secret 进行事件验证。在事件数据穿过拦截器后，在将有效负载数据传递给触发器之前，它会被发送到触发器。您还可以使用拦截器修改 EventListener 规格中引用的关联触发器的行为。
以下示例显示了一个 Trigger 资源的代码片段，名为 vote-trigger，它连接 TriggerBinding 和 TriggerTemplate 资源，以及 interceptors 事件处理器。
```
apiVersion: triggers.tekton.dev/v1alpha1 1
kind: Trigger 2
metadata:
  name: vote-trigger 3
spec:
  serviceAccountName: pipeline 4
  interceptors:
    - ref:
        name: "github" 5
      params: 6
        - name: "secretRef"
          value:
            secretName: github-secret
            secretKey: secretToken
        - name: "eventTypes"
          value: ["push"]
  bindings:
    - ref: vote-app 7
  template: 8
     ref: vote-app
---
apiVersion: v1
kind: Secret 9
metadata:
  name: github-secret
type: Opaque
stringData:
  secretToken: "1234567"
```
1
Trigger 资源的 API 版本。在本例中，v1alpha1。
2
指定 Kubernetes 对象的类型。在本例中, Trigger。
3
用于标识 Trigger 资源的唯一名称。
4
要使用的服务帐户名称。
5
要被引用的拦截器名称。在本例中，是 github。
6
要指定的参数.
7
连接到 TriggerTemplate 资源的 TriggerBinding 资源的名称。
8
连接到 TriggerBinding 资源的 TriggerTemplate 资源的名称。
9
用于验证事件的 Secret。
EventListener 资源提供一个端点或事件接收器（sink），用于使用 JSON 有效负载侦听传入的基于 HTTP 的事件。它从每个 TriggerBinding 资源提取事件参数，然后处理此数据以按照对应的 TriggerTemplate 资源指定的 Kubernetes 资源创建 Kubernetes 资源。EventListener 资源还使用事件 interceptors（拦截器） 在有效负载上执行轻量级事件处理或基本过滤，这可识别有效负载类型并进行自选修改。目前，管道触发器支持五种拦截器：Webhook Interceptors, GitHub 拦截器、GitLab 拦截器、Bitbucket 拦截器 和 Common Expression Language (CEL) 拦截器。
以下示例显示了一个 EventListener 资源，它引用名为 vote-trigger 的 Trigger 资源。
```
apiVersion: triggers.tekton.dev/v1alpha1 1
kind: EventListener 2
metadata:
  name: vote-app 3
spec:
  serviceAccountName: pipeline 4
  triggers:
    - triggerRef: vote-trigger 5
```
1
EventListener 资源的 API 版本。在本例中，v1alpha1。
2
指定 Kubernetes 对象的类型。在本例中，EventListener。
3
用于标识 EventListener 资源的唯一名称。
4
要使用的服务帐户名称。
5
EventListener 资源引用的 Trigger 资源的名称。

4.2.3. 其他资源

有关安装管道的详情，请参阅安装 OpenShift Pipelines。
有关创建自定义 CI/CD 解决方案的详情，请参阅使用 CI/CD Pipelines 创建应用程序。
有关重新加密 TLS 终止的详情，请参阅重新加密终止。
有关安全路由的详情，请参阅安全路由部分。