关于 OpenShift Pipelines

在这个版本中，TektonResult CR 不再支持以下参数：

在这个版本中，删除了对 PipelineResource 命令和 Tekton CLI 的引用的支持：

在此次更新之前，Tekton Operator 不会公开任何自定义的性能配置字段。在这个版本中，作为集群管理员，您可以根据您的需要自定义 TektonConfig CR 中的以下性能配置字段：

这个版本包括以下向后兼容的更改：

如果在集群升级后管道指标功能无法正常工作，请运行以下命令作为临时解决方案：

$ oc get tektoninstallersets.operator.tekton.dev | awk '/pipeline-main-static/ {print $1}' | xargs oc delete tektoninstallersets

在这个版本中，在更改 EmbeddedStatus 功能标记时，PipelineStatus 的协调已被修复。在这个版本中重置以下参数：

当在 Windows 上运行 tkn pac 命令集时，您可能会收到以下出错信息： Command finished with error: not supported by Windows。

临时解决方案：将 NO_COLOR 环境变量设置为 true。

如果 tkn pac resolve 命令使用已模板化的参数值，则运行 tkn pac resolve -f <filename> | oc create -f 命令可能无法提供预期的结果。

临时解决方案： 要缓解这个问题，请通过运行 tkn pac resolve -f <filename> -o tempfile.yaml 命令将 tkn pac resolve 命令的输出保持在一个临时文件中，然后运行 oc create -f tempfile.yaml 命令。例如：tkn pac resolve -f <filename> -o /tmp/pull-request-resolved.yaml && oc create -f /tmp/pull-request-resolved.yaml。

在此次更新之前，如果您将 timeouts.pipeline 参数设置为 0，您将无法设置 timeouts.tasks 参数或 timeouts.finally 参数。这个版本解决了这个问题。现在，当您设置 timeouts.pipeline 参数值时，可以设置 `timeouts.tasks` 参数或 timeouts.finally 参数。例如：

yaml
kind: PipelineRun
spec:
  timeouts:
    pipeline: "0"  # No timeout
    tasks: "0h3m0s"

在此次更新之前，当使用带有内部 OpenShift 镜像 registry 的管道运行时，必须在管道运行定义中硬编码到镜像的 URL。例如：

...
  - name: IMAGE_NAME
    value: 'image-registry.openshift-image-registry.svc:5000/<test_namespace>/<test_pipelinerun>'
...

当在 Pipelines 作为代码上下文中使用管道运行时，这些硬编码值会阻止管道运行定义在不同的集群和命名空间中使用。

在这个版本中，您可以使用动态模板变量，而不是硬编码命名空间和管道运行名称的值，以常规化管道运行定义。例如：

...
  - name: IMAGE_NAME
    value: 'image-registry.openshift-image-registry.svc:5000/{{ target_namespace }}/$(context.pipelineRun.name)'
...

CATALOG_REFRESH_INTERVAL 的值(Tekton Hub CR 中使用的 Hub API ConfigMap 对象中的一个字段)不会更新，无法使用用户提供的自定义值进行更新。

临时解决方案：无.您可以跟踪问题 SRVKP-2854。

因为自定义资源定义转换失败，升级到 OpenShift Pipelines 版本 1.9.x 存在一个已知问题。

临时解决方案：在升级到 OpenShift Pipelines 版本 1.9.x 之前，请执行红帽客户门户网站中解决方案中提到的步骤。

在这个版本中，TaskRun 和 PipelineRun 资源的默认指标级别改为以下值：

apiVersion: v1
kind: ConfigMap
metadata:
  name: config-observability
  namespace: tekton-pipelines
  labels:
    app.kubernetes.io/instance: default
    app.kubernetes.io/part-of: tekton-pipelines
data:
  _example: |
  ...
    metrics.taskrun.level: "task"
    metrics.taskrun.duration-type: "histogram"
    metrics.pipelinerun.level: "pipeline"
    metrics.pipelinerun.duration-type: "histogram"

Red Hat OpenShift Pipelines 1.7.x 作为代码 0.5.x 附带。当前的更新附带了 Pipelines，作为代码 0.10.x。此更改在新控制器的 openshift-pipelines 命名空间中创建新路由。您必须在使用 Pipelines 作为代码的 GitHub Apps 或 Webhook 中更新此路由。要获取路由，请使用以下命令：

$ oc get route -n openshift-pipelines pipelines-as-code-controller \
  --template='https://{{ .spec.host }}'

在这个版本中，Pipelines as Code 更新 tkn-pac CLI 工具中的以下命令：

从 OpenShift Container Platform 4.11 开始，会删除用于安装和升级 Red Hat OpenShift Pipelines Operator 的 preview 和 stable 频道。要安装和升级 Operator，请使用适当的 pipelines-<version> 频道，或最新稳定版本的 latest 频道。例如，要安装 OpenShift Pipelines Operator 版本 1.8.x，请使用 pipelines-1.8 频道。

对 tekton.dev/v1alpha1 API 版本的支持（在 Red Hat OpenShift Pipelines GA 1.6 中已弃用）计划在以后的 Red Hat OpenShift Pipelines GA 1.9 发行版本中删除。

此更改会影响管道组件，其中包括 TaskRun, PipelineRun, Task, Pipeline, 和 tekton.dev/v1alpha1 类似。另外，将现有资源更新为使用 apiVersion: tekton.dev/v1beta1，如 Migrating From Tekton v1alpha1 to Tekton v1beta1 所述。

对 tekton.dev/v1alpha1 API 版本的程序错误修复和支持仅到当前 GA 1.8 生命周期结束为止。

在 Red Hat OpenShift Pipelines 1.8 中，pipelineRunCancelled 状态已弃用，计划在以后的发行版本中被删除。现在，PipelineRun 对象的安全终止已从 alpha 功能提升到 stable 功能。（请参阅 TEP-0058: Graceful Pipeline Run Termination。）另外，您可以使用 Cancelled 状态替换 pipelineRunCancelled 状态。

您不需要更改 Pipeline 和 Task 资源。如果您有会取消管道运行的工具，则必须在下一个发行版本中更新这些工具。这个更改也会影响 CLI、IDE 扩展等工具，以便支持新的 PipelineRun 状态。

由于这个功能默认可用，所以您不再需要在 TektonConfig 自定义资源定义中将 pipeline.enable-api-fields 字段设置为 alpha。

在 Red Hat OpenShift Pipelines 1.8 中，PipelineRun 中的 timeout 字段已弃用。反之，使用 PipelineRun.Timeouts 字段，它现在从 alpha 功能提升到 stable 功能。

由于这个功能默认可用，所以您不再需要在 TektonConfig 自定义资源定义中将 pipeline.enable-api-fields 字段设置为 alpha。

s2i-nodejs 管道无法使用 nodejs:14-ubi8-minimal 镜像流来执行 source-to-image (S2I) 构建。使用该镜像流会生成一个 error building at STEP "RUN /usr/libexec/s2i/assemble": exit status 127 信息。

临时解决方案： 使用 nodejs:14-ubi8 而不是 nodejs:14-ubi8-minimal 镜像流。

当您运行 Maven 和 Jib-Maven 集群任务时，默认容器镜像仅支持 Intel(x86)架构。因此，在 ARM、IBM Power Systems(ppc64le)、IBM Z 和 LinuxONE (s390x) 集群上的任务将失败。

作为临时解决方案，您可以通过将 MAVEN_IMAGE 参数值设置为 maven:3.6.3-adoptopenjdk-11 来指定自定义镜像。

在此次更新之前，如果在 $params["<NAME>"] 或 $params['<NAME>'] 的 <NAME> 中包括了一个句点字符 (.)，则不会提取句点右侧的任何部分。例如，对于 $params["org.ipsum.lorem"]，只会提取y org 部分。

在这个版本中解决了这个问题，$params 可以提取完整的值。例如，$params["org.ipsum.lorem"] 和 $params['org.ipsum.lorem'] 是有效的，<NAME> 的完整值 org.ipsum.lorem 都会被提取。

如果 <NAME> 没有包含在单引号或双引号中，还会抛出一个错误。例如，$params.org.ipsum.lorem 是无效，并生成验证错误。

在此次更新之前，因为存在无效的角色绑定，在 OpenShift Container Platform 4.9 和 4.10 上安装 Red Hat OpenShift Pipelines Operator 会失败，并显示以下错误消息：

error updating rolebinding openshift-operators-prometheus-k8s-read-binding: RoleBinding.rbac.authorization.k8s.io
"openshift-operators-prometheus-k8s-read-binding" is invalid:
roleRef: Invalid value: rbac.RoleRef{APIGroup:"rbac.authorization.k8s.io", Kind:"Role", Name:"openshift-operator-read"}: cannot change roleRef

在这个版本中解决了这个问题，不再会发生失败。

在以前的版本中，使用资源修剪器时，每个命名空间 Operator 创建了一个在独立容器中运行的命令。这个设计在有大量命名空间的集群中消耗太多资源。例如，要运行单个命令，带有 1000 个命名空间的集群会在 pod 中生成 1000 个容器。

在这个版本中解决了这个问题。它将基于命名空间的配置传递给作业，以便所有命令在循环中的一个容器中运行。

在此次更新之前，所有 S2I 构建任务都会失败，并显示类似以下消息的错误：

Error: error writing "0 0 4294967295\n" to /proc/22/uid_map: write /proc/22/uid_map: operation not permitted
time="2022-03-04T09:47:57Z" level=error msg="error writing \"0 0 4294967295\\n\" to /proc/22/uid_map: write /proc/22/uid_map: operation not permitted"
time="2022-03-04T09:47:57Z" level=error msg="(unable to determine exit status)"

在这个版本中，pipeline-scc 安全性上下文约束 (SCC) 与 Buildah 和 S2I 集群任务所需的 SETFCAP 功能兼容。因此，Buildah 和 S2I 构建任务可以成功运行。

要成功运行 Buildah 集群任务和 S2I 构建任务，适用于使用各种语言和框架编写的应用程序，添加以下适当的 steps 对象（如 build 和 push）的代码片段。

securityContext:
  capabilities:
    add: ["SETFCAP"]

当您运行 Maven 和 Jib-Maven 集群任务时，默认容器镜像仅支持 Intel(x86)架构。因此，在 ARM、IBM Power Systems(ppc64le)、IBM Z 和 LinuxONE (s390x) 集群上的任务将失败。作为临时解决方案，您可以通过将 MAVEN_IMAGE 参数值设置为 maven:3.6.3-adoptopenjdk-11 来指定自定义镜像。

您无法使用 nodejs:14-ubi8-minimal 镜像流，因为这样做会生成以下错误：

STEP 7: RUN /usr/libexec/s2i/assemble
/bin/sh: /usr/libexec/s2i/assemble: No such file or directory
subprocess exited with status 127
subprocess exited with status 127
error building at STEP "RUN /usr/libexec/s2i/assemble": exit status 127
time="2021-11-04T13:05:26Z" level=error msg="exit status 127"

在这个版本中添加了 v1beta1 Go API 类型。在这个版本中，触发器支持 v1beta1 API 版本。

在当前发行版本中，v1alpha1 功能已弃用，并将在以后的发行版本中删除。改为使用 v1beta1 功能替代。

在当前发行版本中，默认启用自动运行资源。另外，您可以使用以下新注解为每个命名空间单独配置自动运行任务运行和管道运行：

引入了以下 alpha 功能：

当前发行版本允许您通过在 TektonConfig 自定义资源(CR)中指定 nodeSelector 和 tolerations 值来配置节点选择。Operator 将这些值添加到它创建的所有部署中。

在 Tekton Triggers v0.16.0 中，冗余的 status 标签已从 EventListener 资源的指标中删除。

在当前发行版本中，EventListener 资源会在触发器完成处理前发送响应。

当前发行版本从 EventListener 资源中删除 podTemplate 字段。

当前发行版本从 EventListener 资源规格中删除已弃用的 replicas 字段。

在 Red Hat OpenShift Pipelines 1.6 中，HOME="/tekton/home" 和 workingDir="/workspace" 的值从 Step 对象的规格中删除。

相反，Red Hat OpenShift Pipelines 将 HOME 和 workingDir 设置为运行 Step 对象的容器定义的值。您可以在 Step 对象的规格中覆盖这些值。

要使用旧的行为，您可以将 TektonConfig CR 中的 disable-working-directory-overwrite 和 disable-home-env-overwrite 字段改为 false ：

apiVersion: operator.tekton.dev/v1alpha1
  kind: TektonConfig
  metadata:
    name: config
  spec:
    pipeline:
      disable-working-directory-overwrite: false
      disable-home-env-overwrite: false
  ...

您无法使用 nodejs:14-ubi8-minimal 镜像流，因为这样做会生成以下错误：

STEP 7: RUN /usr/libexec/s2i/assemble
/bin/sh: /usr/libexec/s2i/assemble: No such file or directory
subprocess exited with status 127
subprocess exited with status 127
error building at STEP "RUN /usr/libexec/s2i/assemble": exit status 127
time="2021-11-04T13:05:26Z" level=error msg="exit status 127"

Pipeline 运行和任务运行将由目标命名空间中的 cron 作业自动修剪。cron 作业使用 IMAGE_JOB_PRUNER_TKN 环境变量来获取 tkn image 的值。在这个版本中，TektonConfig 自定义资源包括以下字段：

...
pruner:
  resources:
    - pipelinerun
    - taskrun
  schedule: "*/5 * * * *" # cron schedule
  keep: 2 # delete all keeping n
...

在 OpenShift Container Platform 中，您可以通过修改 TektonConfig 自定义资源中的新参数 clusterTasks 和 pipelinesTemplates 的值来自定义 Tekton Add-ons 组件的安装：

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  profile: all
  targetNamespace: openshift-pipelines
  addon:
    params:
    - name: clusterTasks
      value: "true"
    - name: pipelineTemplates
      value: "true"
...

如果您使用 TektonConfig 创建附加组件，或者直接使用 Tekton Add-ons 创建附加组件，则允许进行自定义。但是，如果没有传递参数，控制器会添加带有默认值的参数。

enableMetrics 参数添加到 TektonConfig 自定义资源中。您可以使用它来禁用服务监控器，这是 OpenShift Container Platform 的 Tekton Pipelines 的一部分。

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  profile: all
  targetNamespace: openshift-pipelines
  pipeline:
    params:
    - name: enableMetrics
      value: "true"
...

添加了用于注册拦截器的 ClusterInterceptor 自定义资源定义，允许您注册您可以插入的新 Interceptor 类型。另外，还会进行以下相关更改：

tkn start [task | clustertask | pipeline] 命令以互动方式启动，并询问 params 值，即使指定了默认参数也是如此。若要停止交互式提示，可在调用 命令时传递 --use-param-defaults 标志。例如：

$ tkn pipeline start build-and-deploy \
    -w name=shared-workspace,volumeClaimTemplateFile=https://raw.githubusercontent.com/openshift/pipelines-tutorial/pipelines-1.13/01_pipeline/03_persistent_volume_claim.yaml \
    -p deployment-name=pipelines-vote-api \
    -p git-url=https://github.com/openshift/pipelines-vote-api.git \
    -p IMAGE=image-registry.openshift-image-registry.svc:5000/pipelines-tutorial/pipelines-vote-api \
    --use-param-defaults

在 when 表达式中，对写入的字段的支持会被删除。when 表达式仅支持使用小写字母编写的字段。

当您将 Red Hat OpenShift Pipelines Operator 升级到 v1.5 时，openshift-client 和 openshift-client-v-1-5-0 集群任务会具有 SCRIPT 参数。但是，ARGS 参数和 git 资源会从 openshift-client 集群任务的规格中删除。这个变化可能会造成问题，只有在 ClusterTask 资源的 name 字段中没有特定版本的集群任务才可以无缝地进行升级。

要防止管道运行出现问题，在升级后使用 SCRIPT 参数，因为它会将之前在 ARGS 参数中指定的值移到集群任务的 SCRIPT 参数中。例如：

...
- name: deploy
  params:
  - name: SCRIPT
    value: oc rollout status <deployment-name>
  runAfter:
    - build
  taskRef:
    kind: ClusterTask
    name: openshift-client
...

当您从 Red Hat OpenShift Pipelines Operator v1.4 升级到 v1.5 时，TektonConfig 自定义资源的配置集名称现在会改变。

disable-home-env-overwrite 和 disable-working-dir-overwrite 字段现已弃用，并将在以后的发行版本中删除。在本发行版本中，这些标志的默认值被设置为 true，以便向后兼容。

EventListener 资源的状态有一个名为 Ready 的新条件。

replicas 在 EventListener spec 中已被弃用。相反，spec.replicas 字段移到 KubernetesResource spec 中的 spec.resources.kubernetesResource.replicas。

git-cli 集群任务使用 alpine/git 基础镜像构建，它预期 /root 作为用户的主目录。但是，这并没有在 git-cli 集群任务中显式设置。

在 Tekton 中，任务的每个步骤都会使用 /tekton/home 覆盖默认主目录，除非另有指定。这会覆盖基础镜像的 $HOME 环境变量，从而导致 git-cli 集群任务失败。

此问题有望在即将发布的版本中解决。对于 Red Hat OpenShift Pipelines 1.5 及更早的版本，您可以使用以下任一临时解决方案来避免 git-cli 集群任务失败：

自定义任务有以下改进：

finally 的任务包括以下改进：

pipelines-scc 安全性上下文约束（SCC）与默认的 pipeline 服务帐户一同使用。此新服务帐户与 anyuid 类似，但 OpenShift Container Platform 4.7 的 SCC 在 YAML 中定义中有一个小的差别：

fsGroup:
  type: MustRunAs

在触发器 spec 和绑定中，弃用的字段 template.name 已被删除，并使用 template.ref 替代。您应该更新所有 eventListener 定义，以使用 ref 字段。

如果您在触发器绑定中有以下配置，触发器会因为不正确处理 JSON 格式抛出错误：

params:
  - name: github_json
    value: $(body)

要解决这个问题：

卸载 Red Hat OpenShift Pipelines Operator 不会删除事件监听程序。

作为临时解决方案，删除 EventListener 和 Pod CRD:

当您运行多架构容器镜像任务时，如果在 IBM Power Systems(ppc64le)或 IBM Z(s390x)集群上没有命令规格，则 TaskRun 资源会失败，并显示以下错误：

Error executing command: fork/exec /bin/bash: exec format error

作为临时解决方案，使用特定架构的容器镜像或指定 sha256 摘要指向正确的架构。要获得 sha256 摘要，请输入：

$ skopeo inspect --raw <image_name>| jq '.manifests[] | select(.platform.architecture == "<architecture>") | .digest'

Steps 规格中的环境变量 $HOME，变量 workingDir 已被弃用，并可能在以后的发行版本中有所变化。目前，在 Step 容器中，HOME 和 workingDir 变量会分别被 /tekton/home 和 /workspace 变量覆盖。

在以后的发行版本中，这两个字段将不会被修改，它将被设置为容器镜像和 Task YAML 中定义的值。在本发行版本中，使用 disable-home-env-overwrite 和 disable-working-directory-overwrite 标记来禁用覆盖 HOME 和 workingDir 变量。

当一个新用户添加到容器时，buildah 集群任务无法正常工作。

当安装 Operator 时，buildah 集群任务的 --storage-driver 标志没有指定，因此它会被设置为默认值。在某些情况下，这会导致存储驱动程序设置不正确。当添加一个新用户时，错误的 storage-driver 会造成 buildah 集群任务失败并带有以下错误：

useradd: /etc/passwd.8: lock file already used
useradd: cannot lock /etc/passwd; try again later.

作为临时解决方案，在 buildah-task.yaml 文件中手工把 --storage-driver 标识的值设置为 overlay：

另外，您还可以直接在 web 控制台中直接修改 buildah 集群任务 YAML 文件：进入 Pipelines → Cluster Tasks → buildah。从 Actions 菜单中选择 Edit Cluster Task，如前所示替换 command 项。

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)

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.13
  - 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

Trigger 资源组合了 TriggerBinding 和 TriggerTemplate 资源，以及可选的 interceptors 事件处理器。

拦截器会处理在 TriggerBinding 资源之前运行的特定平台的所有事件。您可以使用拦截器过滤载荷，验证事件，定义和测试触发器条件，以及实施其他有用的处理。拦截器使用 secret 进行事件验证。在事件数据穿过拦截器后，在将有效负载数据传递给触发器之前，它会被发送到触发器。您还可以使用拦截器修改 EventListener 规格中引用的关联触发器的行为。

以下示例显示了一个 Trigger 资源的代码片段，名为 vote-trigger，它连接 TriggerBinding 和 TriggerTemplate 资源，以及 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"

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/v1beta1 1
kind: EventListener 2
metadata:
  name: vote-app 3
spec:
  taskRunTemplate:
    serviceAccountName: pipeline 4
  triggers:
    - triggerRef: vote-trigger 5