×

Red Hat OpenShift Pipelines 是一个基于 Kubernetes 资源的云原生持续集成和持续交付 (CI/CD) 解决方案。它使用 Tekton 构建块通过抽象底层实现细节来自动化跨多个平台的部署。Tekton 引入了一些标准的自定义资源定义 (CRD),用于定义可在 Kubernetes 发行版之间移植的 CI/CD 管道。

主要功能

  • Red Hat OpenShift Pipelines 是一个无服务器 CI/CD 系统,它使用所有必需的依赖项在隔离的容器中运行管道。

  • Red Hat OpenShift Pipelines 专为在基于微服务的架构上工作的分散式团队而设计。

  • Red Hat OpenShift Pipelines 使用易于扩展并与现有 Kubernetes 工具集成的标准 CI/CD 管道定义,使您可以按需扩展。

  • 您可以使用 Red Hat OpenShift Pipelines 使用 Kubernetes 工具(例如 Source-to-Image (S2I)、Buildah、Buildpacks 和 Kaniko)构建镜像,这些镜像可在任何 Kubernetes 平台上移植。

  • 您可以使用 OpenShift Container Platform 开发人员控制台创建 Tekton 资源、查看管道运行日志并在 OpenShift Container Platform 命名空间中管理管道。

OpenShift Pipelines 概念

本指南详细介绍了各种管道概念。

任务

Task 资源是管道的构建块,由顺序执行的步骤组成。它本质上是输入和输出的函数。任务可以单独运行,也可以作为管道的一部分运行。任务是可重用的,可以在多个管道中使用。

步骤是一系列由任务顺序执行的命令,并实现特定目标,例如构建镜像。每个任务都作为 Pod 运行,每个步骤都在该 Pod 内作为容器运行。由于步骤在同一个 Pod 内运行,因此它们可以访问相同的卷来缓存文件、配置映射和密钥。

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

apiVersion: tekton.dev/v1 (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 任务 API 版本,v1
2 Kubernetes 对象的类型,Task
3 此任务的唯一名称。
4 任务中的参数和步骤列表以及任务使用的 workspace。

此任务启动 Pod,并使用指定的镜像在该 Pod 内运行容器以运行指定的命令。

从 OpenShift Pipelines 1.6 开始,将删除步骤 YAML 文件中的以下默认值

  • HOME 环境变量不再默认为 /tekton/home 目录

  • workingDir 字段不再默认为 /workspace 目录

而是步骤的容器定义 HOME 环境变量和 workingDir 字段。但是,您可以通过在步骤的 YAML 文件中指定自定义值来覆盖默认值。

作为临时措施,为了保持与较旧的 OpenShift Pipelines 版本向后兼容,您可以在 TektonConfig 自定义资源定义中将以下字段设置为 false

spec:
  pipeline:
    disable-working-directory-overwrite: false
    disable-home-env-overwrite: false

when 表达式

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

when 表达式的关键组件如下

  • input: 指定静态输入或变量,例如参数、任务结果和执行状态。您必须输入有效的输入。如果您未输入有效的输入,其值将默认为空字符串。

  • operator: 指定输入与一组values的关系。输入innotin作为您的运算符值。

  • values: 指定一个字符串值数组。输入一个非空静态值或变量数组,例如参数、结果和工作区的绑定状态。

声明的when表达式在任务运行之前进行评估。如果when表达式的值为True,则运行任务;如果when表达式的值为False,则跳过任务。

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

  • 先前任务的结果符合预期。

  • Git 仓库中的文件在上一次提交中已更改。

  • 注册表中存在图像。

  • 可选工作区可用。

以下示例显示了流水线运行的when表达式。只有满足以下条件,流水线运行才会执行create-file任务:path参数为README.md,并且只有当check-file任务的exists结果为yes时,才会执行echo-file-exists任务。

apiVersion: tekton.dev/v1
kind: PipelineRun (1)
metadata:
  generateName: guarded-pr-
spec:
  taskRunTemplate:
    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 流水线中使用的任务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任务的执行状态和任务状态为Succeededcheck-file任务的exists结果为yes,并且path参数为README.md时,才执行finally-task-should-be-executed任务。

OpenShift Container Platform Web 控制台的**流水线运行详细信息**页面显示任务和when表达式的状态如下:

  • 所有条件都满足:任务和when表达式符号(用菱形表示)为绿色。

  • 任何一个条件都不满足:任务被跳过。跳过的任务和when表达式符号为灰色。

  • 所有条件都不满足:任务被跳过。跳过的任务和when表达式符号为灰色。

  • 任务运行失败:失败的任务和when表达式符号为红色。

最终任务

finally任务是使用流水线YAML文件中的finally字段指定的最终任务集。finally任务始终执行流水线中的任务,无论流水线运行是否成功。finally任务在所有流水线任务运行完毕后并行执行,然后相应的流水线退出。

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

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

apiVersion: tekton.dev/v1
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 流水线的唯一名称。
2 克隆Git存储库的共享工作区。
3 将应用程序存储库克隆到共享工作区的任务。
4 清理共享工作区的任务。
5 对在任务运行中要执行的任务的引用。
6 流水线中的任务在运行时需要用于接收输入或提供输出的共享存储卷。
7 任务所需的参数列表。如果参数没有隐式默认值,则必须显式设置其值。
8 嵌入式任务定义。

TaskRun

TaskRun实例化一个任务,以便在集群上使用特定的输入、输出和执行参数来执行。它可以单独调用,也可以作为流水线运行的一部分为流水线中的每个任务调用。

一个任务包含一个或多个步骤,这些步骤执行容器镜像,每个容器镜像执行特定构建工作的一部分。任务运行按指定的顺序执行任务中的步骤,直到所有步骤成功执行或发生故障。PipelineRun会为流水线中的每个任务自动创建一个TaskRun

以下示例显示了一个任务运行,它使用相关的输入参数运行apply-manifests任务。

apiVersion: tekton.dev/v1 (1)
kind: TaskRun (2)
metadata:
  name: apply-manifests-taskrun (3)
spec: (4)
  taskRunTemplate:
    serviceAccountName: pipeline
  taskRef: (5)
    kind: Task
    name: apply-manifests
  workspaces: (6)
  - name: source
    persistentVolumeClaim:
      claimName: source-pvc
1 任务运行API版本v1
2 指定 Kubernetes 对象的类型。在此示例中为TaskRun
3 用于标识此任务运行的唯一名称。
4 任务运行的定义。对于此任务运行,指定了任务和所需的工作区。
5 此任务运行使用的任务引用的名称。此任务运行执行apply-manifests任务。
6 任务运行使用的工作区。

流水线

Pipeline是按特定执行顺序排列的Task资源的集合。它们用于构建复杂的流程,以自动化应用程序的构建、部署和交付。您可以使用包含一个或多个任务的流水线为您的应用程序定义CI/CD工作流程。

Pipeline资源定义由许多字段或属性组成,这些字段或属性共同使流水线能够实现特定目标。每个Pipeline资源定义至少必须包含一个Task资源,该资源会提取特定输入并产生特定输出。根据应用程序的需求,流水线定义还可以包含条件工作区参数资源

以下示例显示了build-and-deploy流水线,该流水线使用openshift-pipelines命名空间中提供的buildah任务从Git存储库构建应用程序镜像。

apiVersion: tekton.dev/v1 (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.17"
  - name: IMAGE
    type: string
    description: image to be built from the code
  tasks: (7)
  - name: fetch-repository
    taskRef:
      resolver: cluster
      params:
      - name: kind
        value: task
      - name: name
        value: git-clone
      - name: namespace
        value: openshift-pipelines
    workspaces:
    - name: output
      workspace: shared-workspace
    params:
    - name: URL
      value: $(params.git-url)
    - name: SUBDIRECTORY
      value: ""
    - name: DELETE_EXISTING
      value: "true"
    - name: REVISION
      value: $(params.git-revision)
  - name: build-image (8)
    taskRef:
      resolver: cluster
      params:
      - name: kind
        value: task
      - name: name
        value: buildah
      - name: namespace
        value: openshift-pipelines
    workspaces:
    - name: source
      workspace: shared-workspace
    params:
    - name: TLSVERIFY
      value: "false"
    - name: IMAGE
      value: $(params.IMAGE)
    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 流水线API版本v1
2 指定 Kubernetes 对象的类型。在此示例中为Pipeline
3 此流水线的唯一名称。
4 指定流水线的定义和结构。
5 流水线中所有任务使用的工作区。
6 流水线中所有任务使用的参数。
7 指定流水线中使用的任务列表。
8 任务build-image,它使用openshift-pipelines命名空间中提供的buildah任务从给定的Git存储库构建应用程序镜像。
9 任务apply-manifests,它使用相同名称的用户定义任务。
10 指定在流水线中运行任务的顺序。在此示例中,只有在build-image任务完成后才会运行apply-manifests任务。

Red Hat OpenShift Pipelines Operator 在openshift-pipelines命名空间中安装 Buildah 任务,并创建具有构建和推送镜像的足够权限的pipeline服务帐户。当与权限不足的不同服务帐户关联时,Buildah 任务可能会失败。

PipelineRun

PipelineRun是一种资源类型,它绑定流水线、工作区、凭据和特定于场景的一组参数值以运行CI/CD工作流程。

流水线运行是流水线的运行实例。它在集群上使用特定的输入、输出和执行参数实例化流水线以执行。它还为流水线运行中的每个任务创建一个任务运行。

流水线按顺序运行任务,直到任务完成或任务失败。status 字段跟踪并记录每个任务运行的进度,并将其存储起来以用于监控和审计。

以下示例使用相关的资源和参数运行 build-and-deploy 流水线

apiVersion: tekton.dev/v1 (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 流水线运行 API 版本 v1
2 Kubernetes 对象的类型。在此示例中,为 PipelineRun
3 用于标识此流水线运行的唯一名称。
4 要运行的流水线的名称。在此示例中,为 build-and-deploy
5 运行流水线所需的参数列表。
6 流水线运行使用的workspace。

工作区 (Workspaces)

建议您在 Red Hat OpenShift Pipelines 中使用工作区而不是 PipelineResource CR,因为 PipelineResource CR 难以调试,范围有限,并且会降低任务的可重用性。

工作区声明任务在运行时需要共享存储卷,以便接收输入或提供输出。工作区无需指定卷的实际位置,而是允许您声明运行时所需的整个文件系统或文件系统的一部分。任务或流水线声明工作区,您必须提供卷的具体位置详细信息。然后,它会在任务运行或流水线运行中挂载到该工作区。这种将卷声明与运行时存储卷分离的方法使任务可重用、灵活且独立于用户环境。

使用工作区,您可以:

  • 存储任务输入和输出

  • 在任务之间共享数据

  • 用作存储在密钥中的凭据的挂载点

  • 用作存储在配置映射中的配置的挂载点

  • 用作组织共享的常用工具的挂载点

  • 创建构建工件缓存以加快作业速度

您可以使用以下方法在 TaskRunPipelineRun 中指定工作区:

  • 只读配置映射或密钥

  • 与其他任务共享的现有持久卷声明

  • 来自提供的卷声明模板的持久卷声明

  • 任务运行完成后将被丢弃的 emptyDir

以下示例显示了 build-and-deploy 流水线的代码片段,该代码片段为流水线中定义的 build-imageapply-manifests 任务声明了一个 shared-workspace 工作区。

apiVersion: tekton.dev/v1
kind: Pipeline
metadata:
  name: build-and-deploy
spec:
  workspaces: (1)
  - name: shared-workspace
  params:
...
  tasks: (2)
  - name: build-image
    taskRef:
      resolver: cluster
      params:
      - name: kind
        value: task
      - name: name
        value: buildah
      - name: namespace
        value: openshift-pipelines
    workspaces: (3)
    - name: source (4)
      workspace: shared-workspace (5)
    params:
    - name: TLSVERIFY
      value: "false"
    - name: IMAGE
      value: $(params.IMAGE)
    runAfter:
    - fetch-repository
  - name: apply-manifests
    taskRef:
      name: apply-manifests
    workspaces: (6)
    - name: source
      workspace: shared-workspace
    runAfter:
      - build-image
...
1 流水线中定义的任务之间共享的工作区列表。流水线可以根据需要定义任意多个工作区。在此示例中,只声明了一个名为 shared-workspace 的工作区。
2 流水线中使用的任务的定义。此代码片段定义了两个任务,build-imageapply-manifests,它们共享一个公共工作区。
3 build-image 任务中使用的工作区列表。任务定义可以包含任意多个工作区。但是,建议任务最多使用一个可写工作区。
4 唯一标识任务中使用的工作区的名称。此任务使用一个名为 source 的工作区。
5 任务使用的流水线工作区的名称。请注意,工作区 source 又使用了名为 shared-workspace 的流水线工作区。
6 apply-manifests 任务中使用的工作区列表。请注意,此任务与 build-image 任务共享 source 工作区。

工作区帮助任务共享数据,并允许您指定流水线中每个任务在执行期间所需的一个或多个卷。您可以创建持久卷声明,或提供一个卷声明模板,该模板将为您创建一个持久卷声明。

以下 build-deploy-api-pipelinerun 流水线运行的代码片段使用卷声明模板为 build-and-deploy 流水线中使用的 shared-workspace 工作区定义存储卷创建一个持久卷声明。

apiVersion: tekton.dev/v1
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 指定将在流水线运行中提供卷绑定的流水线工作区列表。
2 提供卷的流水线工作区的名称。
3 指定一个卷声明模板,该模板创建一个持久卷声明来定义工作区的存储卷。

步骤操作 (Step Actions)

步骤是任务的一部分。如果您在任务中定义步骤,则无法从另一个任务引用此步骤。

但是,您可以在 StepAction 自定义资源 (CR) 中选择定义一个步骤操作。此 CR 包含步骤执行的操作。您可以从步骤引用 StepAction 对象来创建一个执行该操作的步骤。您还可以使用解析器来引用从外部资源获取的 StepAction 定义。

以下示例显示了一个名为 apply-manifests-actionStepAction CR。此步骤操作将清单从源代码树应用到您的 OpenShift Container Platform 环境

apiVersion: tekton.dev/v1
kind: StepAction
metadata:
  name: apply-manifests-action
spec:
  params:
  - name: working_dir
    description: The working directory where the source is located
    type: string (1)
    default: "/workspace/source"
  - name: manifest_dir
    description: The directory in source that contains yaml manifests
    default: "k8s"
  results:
  - name: output
    description: The output of the oc apply command
  image: image-registry.openshift-image-registry.svc:5000/openshift/cli:latest
  env:
  - name: MANIFEST_DIR
    value: $(params.manifest_dir)
  workingDir: $(params.working_dir)
  script: |
      #!/usr/bin/env bash
      oc apply -f "$MANIFEST_DIR" | tee $(results.output)
1 参数的 type 指定是可选的。

StepAction CR 不包含工作区的定义。相反,步骤操作期望包含该操作的任务也提供已挂载的源代码树,通常使用工作区。

StepAction 对象可以定义参数和结果。当您引用此对象时,必须在步骤定义中为 StepAction 对象的参数指定值。StepAction 对象的结果会自动成为步骤的结果。

为了避免使用 shell 的恶意攻击,StepAction CR 不支持在 script 值中使用参数值。相反,您必须使用 env: 部分来定义包含参数值的 environment 变量。

以下示例任务包含一个引用 apply-manifests-action 步骤操作的步骤,提供必要的参数并使用结果

apiVersion: tekton.dev/v1
kind: Task
metadata:
  name: apply-manifests-with-action
spec:
  workspaces:
  - name: source
  params:
  - name: manifest_dir
    description: The directory in source that contains yaml manifests
    type: string
    default: "k8s"
  steps:
  - name: apply
    ref:
      name: apply-manifests-action
    params:
    - name: working_dir
      value: "/workspace/source"
    - name: manifest_dir
      value: $(params.manifest_dir)
  - name: display_result
    script: 'echo $(step.apply.results.output)'

触发器 (Triggers)

触发器与流水线结合使用,可以创建一个完整的 CI/CD 系统,其中 Kubernetes 资源定义整个 CI/CD 执行过程。触发器捕获外部事件(例如 Git 拉取请求)并处理它们以提取关键信息。将此事件数据映射到一组预定义的参数会触发一系列任务,这些任务随后可以创建和部署 Kubernetes 资源并实例化流水线。

例如,您使用 Red Hat OpenShift Pipelines 为您的应用程序定义了一个 CI/CD 工作流程。对于应用程序存储库中的任何更改生效,都必须启动流水线。触发器通过捕获和处理任何更改事件并触发部署具有最新更改的新镜像的流水线运行来自动执行此过程。

触发器包含以下主要资源,这些资源协同工作以形成一个可重用、解耦和自持的 CI/CD 系统

  • TriggerBinding 资源提取事件有效负载中的字段并将其存储为参数。

    以下示例显示了 TriggerBinding 资源的代码片段,该代码片段从接收到的事件有效负载中提取 Git 存储库信息

    apiVersion: triggers.tekton.dev/v1beta1 (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 版本。在此示例中,为 v1beta1
    2 指定 Kubernetes 对象的类型。在此示例中,为 TriggerBinding
    3 用于标识TriggerBinding资源的唯一名称。
    4 将从接收到的事件有效负载中提取并传递给TriggerTemplate资源的参数列表。在此示例中,Git 仓库 URL、名称和版本号是从事件有效负载的主体中提取的。
  • TriggerTemplate资源充当创建资源方式的标准。它指定了如何使用来自TriggerBinding资源的参数化数据。触发器模板接收来自触发器绑定的输入,然后执行一系列操作,最终创建新的管道资源并启动新的管道运行。

    以下示例显示了TriggerTemplate资源的代码片段,它使用从您刚刚创建的TriggerBinding资源接收的 Git 仓库信息来创建管道运行。

    apiVersion: triggers.tekton.dev/v1beta1 (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.17
      - name: git-repo-name
        description: The name of the deployment to be created / patched
    
      resourcetemplates: (5)
      - apiVersion: tekton.dev/v1
        kind: PipelineRun
        metadata:
          name: build-deploy-$(tt.params.git-repo-name)-$(uid)
        spec:
          taskRunTemplate:
            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 版本。在此示例中为v1beta1
    2 指定 Kubernetes 对象的类型。在此示例中为TriggerTemplate
    3 用于标识TriggerTemplate资源的唯一名称。
    4 TriggerBinding资源提供的参数。
    5 模板列表,指定使用通过TriggerBindingEventListener资源接收的参数创建资源的方式。
  • Trigger资源结合了TriggerBindingTriggerTemplate资源,以及可选的interceptors事件处理器。

    拦截器处理在TriggerBinding资源之前运行的特定平台的所有事件。您可以使用拦截器来过滤有效负载、验证事件、定义和测试触发条件以及实现其他有用的处理。拦截器使用密钥进行事件验证。事件数据通过拦截器后,才会进入触发器,然后您才能将有效负载数据传递给触发器绑定。您还可以使用拦截器来修改EventListener规范中引用的关联触发器的行为。

    以下示例显示了一个名为vote-triggerTrigger资源的代码片段,它连接了TriggerBindingTriggerTemplate资源以及interceptors事件处理器。

    apiVersion: triggers.tekton.dev/v1beta1 (1)
    kind: Trigger (2)
    metadata:
      name: vote-trigger (3)
    spec:
      taskRunTemplate:
        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 版本。在此示例中为v1beta1
    2 指定 Kubernetes 对象的类型。在此示例中为Trigger
    3 用于标识Trigger资源的唯一名称。
    4 要使用的服务帐户名称。
    5 要引用的拦截器名称。在此示例中为github
    6 要指定的所需参数。
    7 要连接到TriggerTemplate资源的TriggerBinding资源的名称。
    8 要连接到TriggerBinding资源的TriggerTemplate资源的名称。
    9 用于验证事件的密钥。
  • EventListener资源提供一个端点或事件接收器,用于侦听具有 JSON 有效负载的传入基于 HTTP 的事件。它从每个TriggerBinding资源中提取事件参数,然后处理这些数据以根据相应的TriggerTemplate资源创建 Kubernetes 资源。EventListener资源还使用事件interceptors对有效负载执行轻量级事件处理或基本过滤,这些拦截器标识有效负载的类型并对其进行可选修改。目前,管道触发器支持五种类型的拦截器:_Webhook 拦截器_、_GitHub 拦截器_、_GitLab 拦截器_、_Bitbucket 拦截器_和_通用表达式语言 (CEL) 拦截器_。

    以下示例显示了一个EventListener资源,它引用名为vote-triggerTrigger资源。

    apiVersion: triggers.tekton.dev/v1beta1 (1)
    kind: EventListener (2)
    metadata:
      name: vote-app (3)
    spec:
      taskRunTemplate:
        serviceAccountName: pipeline (4)
      triggers:
        - triggerRef: vote-trigger (5)
    1 EventListener资源的 API 版本。在此示例中为v1beta1
    2 指定 Kubernetes 对象的类型。在此示例中为EventListener
    3 用于标识EventListener资源的唯一名称。
    4 要使用的服务帐户名称。
    5 EventListener资源引用的Trigger资源的名称。

其他资源