使用 Repository 自定义资源 | 代码即流水线 | Red Hat OpenShift Pipelines 1.17

创建 Repository 自定义资源
创建全局 Repository 自定义资源
设置并发限制
更改流水线定义的源分支
自定义参数扩展

Repository 自定义资源 (CR) 具有以下主要功能：

通知代码即流水线处理来自 URL 的事件。
通知代码即流水线流水线运行的命名空间。
引用使用 webhook 方法时 Git 提供商平台所需的 API 密钥、用户名或 API URL。
提供代码库的最后一次流水线运行状态。

创建 Repository 自定义资源

您可以使用 tkn pac CLI 或其他替代方法在目标命名空间中创建 Repository 自定义资源 (CR)。例如：

cat <<EOF|kubectl create -n my-pipeline-ci -f- (1)

apiVersion: "pipelinesascode.tekton.dev/v1alpha1"
kind: Repository
metadata:
  name: project-repository
spec:
  url: "https://github.com/<repository>/<project>"
EOF

1	`my-pipeline-ci` 是目标命名空间。

每当有来自 URL 的事件（例如 https://github.com/<repository>/<project>）时，代码即流水线会进行匹配，然后开始检出 <repository>/<project> 代码库的内容以进行流水线运行，以匹配 .tekton/ 目录中的内容。

您必须在与源代码代码库关联的流水线将要执行的同一命名空间中创建 Repository CR；它不能指向不同的命名空间。
如果多个 Repository CR 匹配同一事件，代码即流水线只会处理最旧的一个。如果您需要匹配特定命名空间，请添加 pipelinesascode.tekton.dev/target-namespace: "<mynamespace>" 注解。这种明确的目标设置可以防止恶意行为者在他们无权访问的命名空间中执行流水线运行。

创建全局 Repository 自定义资源

可以选择在安装 OpenShift Pipelines 的命名空间（通常是 openshift-pipelines）中创建一个全局 Repository 自定义资源 (CR)。如果您创建此 CR，则您在其中指定的设置将默认应用于您创建的所有 Repository CR。

全局 Repository CR 仅为技术预览功能。技术预览功能不受 Red Hat 生产服务级别协议 (SLA) 的支持，并且可能功能不完整。Red Hat 不建议在生产环境中使用它们。这些功能可让您抢先体验即将推出的产品功能，从而能够在开发过程中测试功能并提供反馈。

有关 Red Hat 技术预览功能的支持范围的更多信息，请参阅技术预览功能支持范围。

先决条件

您拥有openshift-pipelines命名空间的管理员访问权限。
您已使用oc命令行工具登录到OpenShift集群。

步骤

在openshift-pipelines命名空间中创建一个名为pipeline-as-code的Repository CR。在此CR中指定所有必需的默认设置。

创建CR的示例命令

$ cat <<EOF|oc create -n openshift-pipelines -f -

apiVersion: "pipelinesascode.tekton.dev/v1alpha1"
kind: Repository
metadata:
  name: pipelines-as-code
spec:
  git_provider:
    secret:
      name: "gitlab-webhook-config"
      key: "provider.token"
    webhook_secret:
      name: "gitlab-webhook-config"
      key: "webhook.secret"
EOF

在此示例中，您创建的所有Repository CR都包含访问您的GitLab存储库的常用密钥。您可以在CR中设置不同的存储库URL和其他设置。

设置并发限制

您可以使用Repository自定义资源定义 (CRD) 中的concurrency_limit规范来定义同时运行的存储库管道运行的最大数量。

apiVersion: "pipelinesascode.tekton.dev/v1alpha1"
kind: Repository
metadata:
  name: my-repo
  namespace: target-namespace
spec:
# ...
  concurrency_limit: <number>
# ...

如果有多个管道运行匹配一个事件，则匹配该事件的管道运行将按字母顺序启动。

例如，如果您在.tekton目录中有三个管道运行，并且您在存储库配置中创建了一个concurrency_limit为1的拉取请求，那么所有管道运行将按字母顺序执行。在任何给定时间，只有一个管道运行处于运行状态，而其余的则排队。

更改管道定义的源分支

默认情况下，在处理推送事件或拉取请求事件时，Pipelines as Code 会从触发事件的分支获取管道定义。您可以使用Repository自定义资源定义 (CRD) 中的pipelinerun_provenance设置从Git存储库提供商（例如main、master或trunk）上配置的默认分支获取定义。

apiVersion: "pipelinesascode.tekton.dev/v1alpha1"
kind: Repository
metadata:
  name: my-repo
  namespace: target-namespace
spec:
# ...
  settings:
    pipelinerun_provenance: "default_branch"
# ...

您可以将此设置用作安全预防措施。使用默认行为，Pipelines as Code 使用提交的拉取请求中的管道定义。使用default-branch设置，管道定义必须合并到默认分支才能运行。此要求确保在合并审查期间对任何更改进行最大可能的验证。

自定义参数扩展

您可以使用 Pipelines as Code 通过使用params字段来扩展PipelineRun资源中的自定义参数。您可以在Repository自定义资源 (CR) 的模板中为自定义参数指定一个值。指定的值将替换管道运行中的自定义参数。

您可以在以下场景中使用自定义参数

定义URL参数，例如基于推送或拉取请求而变化的注册表URL。
定义参数，例如管理员可以管理的帐户UUID，而无需更改Git存储库中的PipelineRun执行。

仅当您无法使用Tekton PipelineRun参数时才使用自定义参数扩展功能，因为Tekton参数是在Pipeline资源中定义的，并与其一起在Git存储库内进行自定义。但是，自定义参数是在Repository CR 所在的位置定义和自定义的。因此，您无法从单点管理您的CI/CD管道。

以下示例显示了Repository CR 中名为company的自定义参数

...
spec:
  params:
    - name: company
      value: "ABC Company"
...

值ABC Company 将替换管道运行中和远程获取的任务中的参数名称company。

您还可以从Kubernetes密钥检索自定义参数的值，如下例所示

...
spec:
  params:
    - name: company
      secretRef:
        name: my-secret
        key: companyname
...

Pipelines as Code 按以下方式解析和使用自定义参数

如果您定义了value和secretRef，Pipelines as Code 将使用value。
如果您在params部分没有name，Pipelines as Code 将不会解析该参数。
如果您有多个具有相同name的params，Pipelines as Code 将使用最后一个参数。

您还可以定义自定义参数，并且仅在满足CEL过滤器指定的条件时才使用其扩展。以下示例显示了在触发拉取请求事件时适用于名为company的自定义参数的CEL过滤器

...
spec:
  params:
    - name: company
      value: "ABC Company"
      filter:
        - name: event
          value: |
      pac.event_type == "pull_request"
...

当您有多个具有相同名称和不同过滤器的参数时，Pipelines as Code 将使用第一个匹配过滤器的参数。因此，Pipelines as Code 允许您根据不同的事件类型扩展参数。例如，您可以组合推送和拉取请求事件。