4.8. 使用 Pipelines as Code


使用 Pipelines 作为 Code,具有所需权限的集群管理员和用户可以将管道模板定义为源代码 Git 存储库的一部分。当由源代码推送或配置的 Git 存储库的拉取请求触发时,该功能将运行管道和报告状态。

4.8.1. 主要特性

作为代码的管道支持以下功能:

  • 在托管 Git 仓库的平台上拉取请求状态并控制。
  • GitHub Checks API 以设置管道运行的状态,包括重新检查。
  • GitHub 拉取请求和提交事件。
  • 在注释中拉取请求操作,如 /retest
  • Git 事件过滤和每个事件一个单独的管道。
  • Pipelines 中的自动任务解析,包括本地任务、Tekton Hub 和远程 URL。
  • 使用 GitHub blob 和对象 API 检索配置。
  • 通过 GitHub 组织的访问控制列表 (ACL),或使用 Prow 风格的 OWNER 文件。
  • 用于管理 bootstrap 和 Pipelines 作为代码软件仓库的 tkn pac CLI 插件。
  • 支持 GitHub App、GitHub Webhook、Bitbucket 服务器和 Bitbucket 云。

4.8.2. 在 OpenShift Container Platform 上安装 Pipelines 作为代码

在安装 Red Hat OpenShift Pipelines Operator 时,默认将安装 Pipelines 作为代码。如果您使用 Pipelines 1.7 或更高版本,请跳过将 Pipelines 作为代码手动安装的步骤。

要使用 Operator 禁用 Pipelines as Code 的默认安装,请在 TektonConfig 自定义资源中将 enable 参数的值设置为 false

...
 spec:
    platforms:
      openshift:
        pipelinesAsCode:
          enable: false
          settings:
            application-name: Pipelines as Code CI
            auto-configure-new-github-repo: "false"
            bitbucket-cloud-check-source-ip: "true"
            hub-catalog-name: tekton
            hub-url: https://api.hub.tekton.dev/v1
            remote-tasks: "true"
            secret-auto-create: "true"
...

另外,您可以运行以下命令:

$ oc patch tektonconfig config --type="merge" -p '{"spec": {"platforms": {"openshift":{"pipelinesAsCode": {"enable": false}}}}}'

要使用 Red Hat OpenShift Pipelines Operator 启用 Pipelines 的默认安装,在 TektonConfig 自定义资源中将 enable 参数的值设置为 true

...
spec:
    addon:
      enablePipelinesAsCode: false
...

另外,您可以运行以下命令:

$ oc patch tektonconfig config --type="merge" -p '{"spec": {"platforms": {"openshift":{"pipelinesAsCode": {"enable": true}}}}}'

4.8.3. 将管道安装为代码 CLI

集群管理员可以在本地机器中使用 tkn pacopc CLI 工具,或作为容器进行测试。当您为 Red Hat OpenShift Pipelines 安装 tkn CLI 时,tkn pacopc CLI 工具会自动安装。

您可以为支持的平台安装 tkn pacopc 版本 1.9.1 二进制文件:

4.8.4. 使用带有 Git 存储库托管服务提供商的 Pipelines as Code。

安装 Pipelines 作为代码后,集群管理员可以配置 Git 存储库托管服务提供商。目前,支持以下服务:

  • GitHub 应用程序
  • GitHub Webhook
  • GitLab
  • Bitbucket 服务器
  • Bitbucket 云
注意

GitHub App 是与 Pipelines as Code 搭配使用的建议服务。

4.8.5. 使用带有 GitHub 应用程序的 Pipelines as Code

GitHub Apps 充当 Red Hat OpenShift Pipelines 的集点,并为 OpenShift Pipelines 提供了基于 Git 的工作流的优势。集群管理员可以为所有集群用户配置单个 GitHub 应用程序。对于 GitHub Apps 需要使用 Pipelines 作为代码,请确保 GitHub App 的 Webhook 指向 Pipelines,作为代码事件监听器路由(或入口端点)用于侦听 GitHub 事件。

4.8.5.1. 配置 GitHub 应用程序

集群管理员可以通过运行以下命令来创建 GitHub 应用程序:

$ tkn pac bootstrap github-app

如果没有安装 tkn pac CLI 插件,您可以手动创建 GitHub App。

流程

要手动为 Pipelines 作为代码创建和配置 GitHub 应用程序,请执行以下步骤:

  1. 登录您的 GitHub 帐户。
  2. 进入 Settings Developer settings GitHub Apps,然后点 New GitHub App
  3. 在 GitHub App 表单中提供以下信息:

    • GitHub 应用程序名称OpenShift Pipelines
    • 主页 URL :OpenShift 控制台 URL
    • Webhook URL :作为代码路由或入口 URL 的 Pipelines。您可以通过运行命令 echo https://$(oc get route -n openshift-pipelines pipelines-as-code-controller -o jsonpath='{.spec.host}') 来找到它。
    • Webhook secret :一个任意的机密。您可以通过执行命令 openssl rand -hex 20 来生成 secret。
  4. 选择以下仓库权限

    • Checks: Read & Write
    • Contents: Read & Write
    • Issues: Read & Write
    • Metadata: Read-only
    • Pull request: Read & Write
  5. 选择以下机构权限

    • Members: Readonly
    • Plan: Readonly
  6. 选择以下用户权限

    • Commit comment
    • Issue comment
    • Pull request
    • Pull request review
    • Pull request review comment
    • push
  7. Create GitHub App
  8. 在新创建的 GitHub App 的 Details 页面中,记录顶部显示的 App ID
  9. Private key 部分,点 Generate Private key 自动生成并下载 GitHub 应用的私钥。安全地存储私钥,以备将来参考和使用。

4.8.5.2. 配置 Pipelines as Code 来访问一个 GitHub 应用程序

要将 Pipelines as Code 配置为访问新创建的 GitHub 应用程序,请执行以下命令:

+

$ oc -n openshift-pipelines create secret generic pipelines-as-code-secret \
        --from-literal github-private-key="$(cat <PATH_PRIVATE_KEY>)" \ 1
        --from-literal github-application-id="<APP_ID>" \ 2
        --from-literal webhook.secret="<WEBHOOK_SECRET>" 3
1
配置 GitHub 应用程序时下载的私钥的路径。
2
GitHub 应用程序的 App ID
3
创建 GitHub 应用程序时提供的 webhook secret。
注意

Pipelines as Code 通过检测从 GitHub Enterprise 集的标头集并将其用于 GitHub Enterprise API 授权 URL 来自动工作。

4.8.5.3. 在管理员视角中创建 GitHub 应用程序

作为集群管理员,您可以使用 OpenShift Container Platform 集群配置 GitHub 应用程序,以使用 Pipelines as Code。此配置允许您执行构建部署所需的一组任务。

先决条件

您已从 Operator Hub 安装了 Red Hat OpenShift Pipelines pipelines-1.10 operator。

流程

  1. 在 Administrator 视角中,使用导航窗格进入到 Pipelines
  2. Pipelines 页面中点 Setup GitHub App
  3. 输入您的 GitHub 应用程序名称。例如,pipelines-ci-clustername-testui
  4. Setup
  5. 在浏览器中提示时输入您的 Git 密码。
  6. Create GitHub App for <username>,其中 <username> 是您的 GitHub 的用户名。

验证

成功创建 GitHub 应用程序后,OpenShift Container Platform Web 控制台会打开并显示应用程序的详情。

GitHub 应用程序详情

GitHub App 的详细信息保存为 openShift-pipelines 命名空间中的 secret。

要查看与 GitHub 应用程序关联的名称、链接和 secret 等详情,请进入到 Pipelines 并点 View GitHub App

4.8.6. 使用带有 GitHub Webhook 的 Pipelines as Code

如果无法创建 GitHub 应用程序,在您的仓库中使用带有 GitHub Webhook 的 Pipelines as Code。但是,使用带有 GitHub Webhook 的 Pipelines as Code 并不代表您可以访问 GitHub Check Runs API。任务的状态在拉取请求中作为注释添加,它在 Checks 选项卡中没有提供。

注意

带有 GitHub Webhook 的 Pipelines as Code 不支持 /retest/ok-to-test 等 GitOps 注释。要重启持续集成 (CI),请创建一个到存储库的新提交。例如,要在不进行任何更改的情况下创建新提交,您可以使用以下命令:

$ git --amend -a --no-edit && git push --force-with-lease <origin> <branchname>

先决条件

  • 确保在集群中安装了 Pipelines as Code。
  • 为了授权,请在 GitHub 上创建一个个人访问令牌。

    • 要生成一个安全的、细颗粒的令牌,将其范围限制为一个特定的存储库,并授予以下权限:

      表 4.7. 细粒度令牌的权限
      Name权限

      管理

      只读

      元数据

      只读

      内容

      只读

      提交状态

      读和写

      Pull request

      读和写

      Webhook

      读和写

    • 要使用经典令牌,将范围设置为 public_repo(公共存储库)和 repo(私有存储库)。另外,提供一个短的令牌过期周期,并在其他位置记录下令牌。

      注意

      如果要使用 tkn pac CLI 配置 webhook,请添加 admin:repo_hook 范围。

流程

  1. 配置 Webhook 并创建一个 Repository 自定义资源 (CR)。

    • 要配置 webhook 并使用 tkn pac CLI 工具自动创建一个 Repository CR,请使用以下命令:

      $ tkn pac create repo

      互动输出示例

      ? Enter the Git repository url (default: https://github.com/owner/repo):
      ? Please enter the namespace where the pipeline should run (default: repo-pipelines):
      ! Namespace repo-pipelines is not found
      ? Would you like me to create the namespace repo-pipelines? Yes
      ✓ Repository owner-repo has been created in repo-pipelines namespace
      ✓ Setting up GitHub Webhook for Repository https://github.com/owner/repo
      👀 I have detected a controller url: https://pipelines-as-code-controller-openshift-pipelines.apps.example.com
      ? Do you want me to use it? Yes
      ? Please enter the secret to configure the webhook for payload validation (default: sJNwdmTifHTs):  sJNwdmTifHTs
      ℹ ️You now need to create a GitHub personal access token, please checkout the docs at https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token for the required scopes
      ? Please enter the GitHub access token:  ****************************************
      ✓ Webhook has been created on repository owner/repo
      🔑 Webhook Secret owner-repo has been created in the repo-pipelines namespace.
      🔑 Repository CR owner-repo has been updated with webhook secret in the repo-pipelines namespace
      ℹ Directory .tekton has been created.
      ✓ We have detected your repository using the programming language Go.
      ✓ A basic template has been created in /home/Go/src/github.com/owner/repo/.tekton/pipelinerun.yaml, feel free to customize it.

    • 要配置 webhook 并 手动创建 Repository CR,请执行以下步骤:

      1. 在 OpenShift 集群中,提取 Pipelines as Code 控制器的公共 URL。

        $ echo https://$(oc get route -n pipelines-as-code pipelines-as-code-controller -o jsonpath='{.spec.host}')
      2. 在 GitHub 存储库或机构中执行以下步骤:

        1. 进入 Settings -> Webhooks 并点 Add webhook
        2. Payload URL 设置为 Pipelines as Code 的公共 URL。
        3. 将内容类型选为 application/json
        4. 添加 webhook secret 并在另一个位置记录它。在本地机器上安装 openssl 后,生成一个随机 secret。

          $ openssl rand -hex 20
        5. Let me select individual events 并选择这些事件:Commit comments, Issue comments, Pull request, 和 Pushes.
        6. 点击 Add webhook
      3. 在 OpenShift 集群中,使用个人访问令牌和 webhook secret 创建一个 Secret 对象。

        $ oc -n target-namespace create secret generic github-webhook-config \
          --from-literal provider.token="<GITHUB_PERSONAL_ACCESS_TOKEN>" \
          --from-literal webhook.secret="<WEBHOOK_SECRET>"
      4. 创建 Repository CR。

        示例: Repository CR

        apiVersion: "pipelinesascode.tekton.dev/v1alpha1"
        kind: Repository
        metadata:
          name: my-repo
          namespace: target-namespace
        spec:
          url: "https://github.com/owner/repo"
          git_provider:
            secret:
              name: "github-webhook-config"
              key: "provider.token" # Set this if you have a different key in your secret
            webhook_secret:
              name: "github-webhook-config"
              key: "webhook.secret" # Set this if you have a different key for your secret

        注意

        Pipelines as Code 假设 OpenShift Secret 对象和 Repository CR 位于同一命名空间中。

  2. 可选: 对于现有的 Repository CR,请添加多个 GitHub Webhook secret 或为已删除的 secret 提供替换。

    1. 使用 tkn pac CLI 工具添加 webhook。

      示例:使用 tkn pac CLI 的额外 Webhook

      $ tkn pac webhook add -n repo-pipelines

      互动输出示例

      ✓ Setting up GitHub Webhook for Repository https://github.com/owner/repo
      👀 I have detected a controller url: https://pipelines-as-code-controller-openshift-pipelines.apps.example.com
      ? Do you want me to use it? Yes
      ? Please enter the secret to configure the webhook for payload validation (default: AeHdHTJVfAeH):  AeHdHTJVfAeH
      ✓ Webhook has been created on repository owner/repo
      🔑 Secret owner-repo has been updated with webhook secert in the repo-pipelines namespace.

    2. 更新现有 OpenShift Secret 对象中的 webhook.secret 密钥。
  3. 可选: 对于现有的 Repository CR,更新个人访问令牌。

    • 使用 tkn pac CLI 工具更新个人访问令牌。

      示例:使用 tkn pac CLI 更新个人访问令牌

      $ tkn pac webhook update-token -n repo-pipelines

      互动输出示例

      ? Please enter your personal access token:  ****************************************
      🔑 Secret owner-repo has been updated with new personal access token in the repo-pipelines namespace.

    • 或者,通过修改 Repository CR 来更新个人访问令牌。

      1. Repository CR 中查找 secret 的名称。

        ...
        spec:
          git_provider:
            secret:
              name: "github-webhook-config"
        ...
      2. 使用 oc patch 命令更新 $target_namespace 命名空间中的 $NEW_TOKEN 的值。

        $ oc -n $target_namespace patch secret github-webhook-config -p "{\"data\": {\"provider.token\": \"$(echo -n $NEW_TOKEN|base64 -w0)\"}}"

4.8.7. 在 GitLab 中使用 Pipelines as Code

如果您的机构或项目使用 GitLab 作为首选平台,您可以在 GitLab 上使用带有 webhook 的仓库的 Pipelines as Code。

先决条件

  • 确保在集群中安装了 Pipelines as Code。
  • 为授权,请生成个人访问令牌作为 GitLab 上项目或机构的管理器。

    注意
    • 如果要使用 tkn pac CLI 配置 webhook,请将 admin:repo_hook 范围添加到令牌中。
    • 使用范围被设置为针对特定项目的令牌无法提供对从已分叉存储库发送的合并请求 (MR) 的 API 访问。在这种情况下,Pipelines as Code 会以一条 MR 评论的方式显示结果。

流程

  1. 配置 Webhook 并创建一个 Repository 自定义资源 (CR)。

    • 要配置 webhook 并使用 tkn pac CLI 工具自动创建一个 Repository CR,请使用以下命令:

      $ tkn pac create repo

      互动输出示例

      ? Enter the Git repository url (default: https://gitlab.com/owner/repo):
      ? Please enter the namespace where the pipeline should run (default: repo-pipelines):
      ! Namespace repo-pipelines is not found
      ? Would you like me to create the namespace repo-pipelines? Yes
      ✓ Repository repositories-project has been created in repo-pipelines namespace
      ✓ Setting up GitLab Webhook for Repository https://gitlab.com/owner/repo
      ? Please enter the project ID for the repository you want to be configured,
        project ID refers to an unique ID (e.g. 34405323) shown at the top of your GitLab project : 17103
      👀 I have detected a controller url: https://pipelines-as-code-controller-openshift-pipelines.apps.example.com
      ? Do you want me to use it? Yes
      ? Please enter the secret to configure the webhook for payload validation (default: lFjHIEcaGFlF):  lFjHIEcaGFlF
      ℹ ️You now need to create a GitLab personal access token with `api` scope
      ℹ ️Go to this URL to generate one https://gitlab.com/-/profile/personal_access_tokens, see https://is.gd/rOEo9B for documentation
      ? Please enter the GitLab access token:  **************************
      ? Please enter your GitLab API URL::  https://gitlab.com
      ✓ Webhook has been created on your repository
      🔑 Webhook Secret repositories-project has been created in the repo-pipelines namespace.
      🔑 Repository CR repositories-project has been updated with webhook secret in the repo-pipelines namespace
      ℹ Directory .tekton has been created.
      ✓ A basic template has been created in /home/Go/src/gitlab.com/repositories/project/.tekton/pipelinerun.yaml, feel free to customize it.

    • 要配置 webhook 并 手动创建 Repository CR,请执行以下步骤:

      1. 在 OpenShift 集群中,提取 Pipelines as Code 控制器的公共 URL。

        $ echo https://$(oc get route -n pipelines-as-code pipelines-as-code-controller -o jsonpath='{.spec.host}')
      2. 在 GitLab 项目中,执行以下步骤:

        1. 使用左侧边栏进入 Settings -> Webhooks
        2. URL 设置为 Pipelines as Code 控制器公共 URL。
        3. 添加 webhook secret 并在另一个位置记录它。在本地机器上安装 openssl 后,生成一个随机 secret。

          $ openssl rand -hex 20
        4. Let me select individual events 并选择这些事件:Commit comments, Issue comments, Pull request, 和 Pushes.
        5. Save Changes
      3. 在 OpenShift 集群中,使用个人访问令牌和 webhook secret 创建一个 Secret 对象。

        $ oc -n target-namespace create secret generic gitlab-webhook-config \
          --from-literal provider.token="<GITLAB_PERSONAL_ACCESS_TOKEN>" \
          --from-literal webhook.secret="<WEBHOOK_SECRET>"
      4. 创建 Repository CR。

        示例: Repository CR

        apiVersion: "pipelinesascode.tekton.dev/v1alpha1"
        kind: Repository
        metadata:
          name: my-repo
          namespace: target-namespace
        spec:
          url: "https://gitlab.com/owner/repo" 1
          git_provider:
            secret:
              name: "gitlab-webhook-config"
              key: "provider.token" # Set this if you have a different key in your secret
            webhook_secret:
              name: "gitlab-webhook-config"
              key: "webhook.secret" # Set this if you have a different key for your secret

        1
        目前,Pipelines as Code 不会自动检测 GitLab 的私有实例。在这种情况下,在 git_provider.url spec 下指定 API URL。通常,您可以使用 git_provider.url spec 手动覆盖 API URL。
    注意
    • Pipelines as Code 假设 OpenShift Secret 对象和 Repository CR 位于同一命名空间中。
  2. 可选: 对于现有的 Repository CR,请添加多个 GitLab Webhook secret 或为已删除的 secret 提供替换。

    1. 使用 tkn pac CLI 工具添加 webhook。

      示例:使用 tkn pac CLI 添加额外的 Webhook

      $ tkn pac webhook add -n repo-pipelines

      互动输出示例

      ✓ Setting up GitLab Webhook for Repository https://gitlab.com/owner/repo
      👀 I have detected a controller url: https://pipelines-as-code-controller-openshift-pipelines.apps.example.com
      ? Do you want me to use it? Yes
      ? Please enter the secret to configure the webhook for payload validation (default: AeHdHTJVfAeH):  AeHdHTJVfAeH
      ✓ Webhook has been created on repository owner/repo
      🔑 Secret owner-repo has been updated with webhook secert in the repo-pipelines namespace.

    2. 更新现有 OpenShift Secret 对象中的 webhook.secret 密钥。
  3. 可选: 对于现有的 Repository CR,更新个人访问令牌。

    • 使用 tkn pac CLI 工具更新个人访问令牌。

      示例:使用 tkn pac CLI 更新个人访问令牌

      $ tkn pac webhook update-token -n repo-pipelines

      互动输出示例

      ? Please enter your personal access token:  ****************************************
      🔑 Secret owner-repo has been updated with new personal access token in the repo-pipelines namespace.

    • 或者,通过修改 Repository CR 来更新个人访问令牌。

      1. Repository CR 中查找 secret 的名称。

        ...
        spec:
          git_provider:
            secret:
              name: "gitlab-webhook-config"
        ...
      2. 使用 oc patch 命令更新 $target_namespace 命名空间中的 $NEW_TOKEN 的值。

        $ oc -n $target_namespace patch secret gitlab-webhook-config -p "{\"data\": {\"provider.token\": \"$(echo -n $NEW_TOKEN|base64 -w0)\"}}"

4.8.8. 在 Bitbucket Cloud 中使用 Pipelines as Code

如果您的机构或项目使用 Bitbucket Cloud 作为首选平台,您可以在 Bitbucket Cloudb 上使用带有 webhook 的仓库的 Pipelines as Code。

先决条件

  • 确保在集群中安装了 Pipelines as Code。
  • 在 Bitbucket Cloud 上创建一个应用程序密码。

    • 选中以下框,为令牌添加适当的权限:

      • 账户:Email, Read
      • 工作区成员资格: ReadWrite
      • 项目: Read,Write
      • Issues: Read,Write
      • Pull requests: Read,Write

        注意
        • 如果要使用 tkn pac CLI 配置 webhook,请在令牌中添加 Webhooks:ReadWrite 权限。
        • 生成后,在另外一个位置保持密码或令牌的副本。

流程

  1. 配置 Webhook 并创建一个 Repository CR。

    • 要配置 webhook 并使用 tkn pac CLI 工具自动创建一个 Repository CR,请使用以下命令:

      $ tkn pac create repo

      互动输出示例

      ? Enter the Git repository url (default: https://bitbucket.org/workspace/repo):
      ? Please enter the namespace where the pipeline should run (default: repo-pipelines):
      ! Namespace repo-pipelines is not found
      ? Would you like me to create the namespace repo-pipelines? Yes
      ✓ Repository workspace-repo has been created in repo-pipelines namespace
      ✓ Setting up Bitbucket Webhook for Repository https://bitbucket.org/workspace/repo
      ? Please enter your bitbucket cloud username:  <username>
      ℹ ️You now need to create a Bitbucket Cloud app password, please checkout the docs at https://is.gd/fqMHiJ for the required permissions
      ? Please enter the Bitbucket Cloud app password:  ************************************
      👀 I have detected a controller url: https://pipelines-as-code-controller-openshift-pipelines.apps.example.com
      ? Do you want me to use it? Yes
      ✓ Webhook has been created on repository workspace/repo
      🔑 Webhook Secret workspace-repo has been created in the repo-pipelines namespace.
      🔑 Repository CR workspace-repo has been updated with webhook secret in the repo-pipelines namespace
      ℹ Directory .tekton has been created.
      ✓ A basic template has been created in /home/Go/src/bitbucket/repo/.tekton/pipelinerun.yaml, feel free to customize it.

    • 要配置 webhook 并 手动创建 Repository CR,请执行以下步骤:

      1. 在 OpenShift 集群中,提取 Pipelines as Code 控制器的公共 URL。

        $ echo https://$(oc get route -n pipelines-as-code pipelines-as-code-controller -o jsonpath='{.spec.host}')
      2. 在 Bitbucket Cloud 上,执行以下步骤:

        1. 使用 Bitbucket Cloud 存储库的左侧导航窗格,进入 Repository settings -> Webhooks,然后点 Add webhook
        2. 设置 Title。例如,"Pipelines as Code"。
        3. URL 设置为 Pipelines as Code 控制器公共 URL。
        4. 选择这些事件: Repository: Push,Pull Request: Created,Pull Request: Updated, 和 Pull Request: Comment created.
        5. 点击 Save
      3. 在 OpenShift 集群中,使用目标命名空间中的 app 密码创建一个 Secret 对象。

        $ oc -n target-namespace create secret generic bitbucket-cloud-token \
          --from-literal provider.token="<BITBUCKET_APP_PASSWORD>"
      4. 创建 Repository CR。

        示例: Repository CR

        apiVersion: "pipelinesascode.tekton.dev/v1alpha1"
        kind: Repository
        metadata:
          name: my-repo
          namespace: target-namespace
        spec:
          url: "https://bitbucket.com/workspace/repo"
          branch: "main"
          git_provider:
            user: "<BITBUCKET_USERNAME>" 1
            secret:
              name: "bitbucket-cloud-token" 2
              key: "provider.token" # Set this if you have a different key in your secret

        1
        您只能通过所有者文件中的 ACCOUNT_ID 引用用户。
        2
        Pipelines as Code 假设 git_provider.secret spec 引用的 secret 和Repository CR 位于同一命名空间中。
    注意
    • Bitbucket 云不支持 tkn pac createtkn pac bootstrap 命令。
    • Bitbucket 云不支持 Webhook secret。为了保护有效负载并防止 CI 被劫持,Pipelines as Code 会获取 Bitbucket 云 IP 地址列表,并确保 Webhook 接收仅来自这些 IP 地址。

      • 要禁用这个默认行为,在 Pipelines 中将 bitbucket-cloud-check-source-ip 键设置为 false,作为 pipelines-as-code 命名空间的代码配置映射中。
      • 要允许额外的安全 IP 地址或网络,请将它们作为逗号分隔的值添加到 Pipelines 中的 bitbucket-cloud-additional-source-ip 键中,作为 pipelines-as-code 命名空间的代码配置映射。
  2. 可选: 对于现有的 Repository CR,请添加多个 Bitbucket Cloud Webhook secret 或为已删除的 secret 提供替换。

    1. 使用 tkn pac CLI 工具添加 webhook。

      示例:使用 tkn pac CLI 添加额外的 Webhook

      $ tkn pac webhook add -n repo-pipelines

      互动输出示例

      ✓ Setting up Bitbucket Webhook for Repository https://bitbucket.org/workspace/repo
      ? Please enter your bitbucket cloud username:  <username>
      👀 I have detected a controller url: https://pipelines-as-code-controller-openshift-pipelines.apps.example.com
      ? Do you want me to use it? Yes
      ✓ Webhook has been created on repository workspace/repo
      🔑 Secret workspace-repo has been updated with webhook secret in the repo-pipelines namespace.

      注意

      只有在 Repository CR 在 default 命名空间以外的命名空间中存在时,才在运行 tkn pac webhook add 命令时使用 [-n <namespace>] 选项。

    2. 更新现有 OpenShift Secret 对象中的 webhook.secret 密钥。
  3. 可选: 对于现有的 Repository CR,更新个人访问令牌。

    • 使用 tkn pac CLI 工具更新个人访问令牌。

      示例:使用 tkn pac CLI 更新个人访问令牌

      $ tkn pac webhook update-token -n repo-pipelines

      互动输出示例

      ? Please enter your personal access token:  ****************************************
      🔑 Secret owner-repo has been updated with new personal access token in the repo-pipelines namespace.

      注意

      只有在 Repository CR 在 default 命名空间以外的命名空间中存在时,才在 tkn pac webhook update-token 命令中使用 [-n <namespace>] 选项。

    • 或者,通过修改 Repository CR 来更新个人访问令牌。

      1. Repository CR 中查找 secret 的名称。

        ...
        spec:
          git_provider:
            user: "<BITBUCKET_USERNAME>"
            secret:
              name: "bitbucket-cloud-token"
              key: "provider.token"
        ...
      2. 使用 oc patch 命令更新 $target_namespace 命名空间中的 $password 的值。

        $ oc -n $target_namespace patch secret bitbucket-cloud-token -p "{\"data\": {\"provider.token\": \"$(echo -n $NEW_TOKEN|base64 -w0)\"}}"

4.8.9. 在 Bitbucket Server 中使用 Pipelines as Code

如果您的机构或项目使用 Bitbucket Cloud 作为首选平台,您可以在 Bitbucket Server 上使用带有 webhook 的仓库的 Pipelines as Code。

先决条件

  • 确保在集群中安装了 Pipelines as Code。
  • 在 Bitbucket 服务器上,生成个人访问令牌作为项目管理器,并将它保存到一个其他位置中。

    注意
    • 令牌必须具有 PROJECT_ADMINREPOSITORY_ADMIN 权限。
    • 令牌必须有权访问拉取请求中分叉的存储库。

流程

  1. 在 OpenShift 集群中,提取 Pipelines as Code 控制器的公共 URL。

    $ echo https://$(oc get route -n pipelines-as-code pipelines-as-code-controller -o jsonpath='{.spec.host}')
  2. 在 Bitbucket 服务器上,执行以下步骤:

    1. 使用 Bitbucket Data Center 存储库的左侧导航窗格,进入 Repository settings -> Webhooks 并点 Add webhook
    2. 设置 Title。例如,"Pipelines as Code"。
    3. URL 设置为 Pipelines as Code 控制器公共 URL。
    4. 添加 webhook secret,并将它的副本保存到备用位置。如果您在本地机器上安装了 openssl,使用以下命令生成随机 secret:

      $ openssl rand -hex 20
    5. 选择以下事件:

      • Repository: Push
      • Repository: Modified
      • Pull Request: Opened
      • Pull Request: Source branch updated
      • Pull Request: Comment added
    6. 点击 Save
  3. 在 OpenShift 集群中,使用目标命名空间中的 app 密码创建一个 Secret 对象。

    $ oc -n target-namespace create secret generic bitbucket-server-webhook-config \
      --from-literal provider.token="<PERSONAL_TOKEN>" \
      --from-literal webhook.secret="<WEBHOOK_SECRET>"
  4. 创建 Repository CR。

    示例: Repository CR

    ---
      apiVersion: "pipelinesascode.tekton.dev/v1alpha1"
      kind: Repository
      metadata:
        name: my-repo
        namespace: target-namespace
      spec:
        url: "https://bitbucket.com/workspace/repo"
        git_provider:
          url: "https://bitbucket.server.api.url/rest" 1
          user: "<BITBUCKET_USERNAME>" 2
          secret: 3
            name: "bitbucket-server-webhook-config"
            key: "provider.token" # Set this if you have a different key in your secret
          webhook_secret:
            name: "bitbucket-server-webhook-config"
            key: "webhook.secret" # Set this if you have a different key for your secret

    1
    确保具有不带 /api/v1.0 后缀的正确的 Bitbucket 服务器 API URL。通常,默认安装有一个 /rest 后缀。
    2
    您只能通过所有者文件中的 ACCOUNT_ID 引用用户。
    3
    Pipelines as Code 假设 git_provider.secret spec 引用的 secret 和Repository CR 位于同一命名空间中。
    注意

    Bitbucket 服务器不支持 tkn pac createtkn pac bootstrap 命令。

4.8.10. 使用自定义证书与 Pipelines as Code 进行交互

要将 Pipelines as Code 配置为使用通过私有签名或自定义证书进行访问的 Git 存储库,您可以将证书公开给 Pipelines as Code。

流程

  • 如果您使用 Red Hat OpenShift Pipelines Operator 安装了 Pipelines as Code,则可以使用 Proxy 对象将自定义证书添加到集群中。Operator 在所有 Red Hat OpenShift Pipelines 组件和工作负载中公开证书,包括 Pipelines as Code。

4.8.11. 在 Pipelines as Code 中使用 Repository CRD

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

  • 告知 Pipelines as Code 关于处理来自一个 URL 事件的信息。
  • 告知 Pipelines as Code 关于管道运行的命名空间信息。
  • 使用 webhook 方法时,对于 Git 供应商平台需要需要引用 API secret、用户名或 API URL。
  • 为存储库提供最后的管道运行状态。

您可以使用 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>)的事件,Pipelines as Code 会匹配它并开始为管道运行签出 <repository>/<project> 存储库的内容以匹配 .tekton/ 目录中的内容。

注意
  • 您必须在与要执行的源代码存储库关联的管道所在的同一命名空间中创建 Repository CRD,它不能针对不同的命名空间。
  • 如果多个 Repository CRD 与同一事件匹配,Pipelines as Code 将只会处理最老的一个。如果您需要与特定命名空间匹配,请添加 pipelinesascode.tekton.dev/target-namespace: "<mynamespace>" 注解。通过这种显式目标,可防止恶意攻击者在其无法访问的命名空间中执行一个管道运行。

4.8.11.1. 在 Repository CRD 中设置并发限制

您可以使用 Repository CRD 中的 concurrency_limit spec 来定义为存储库同时运行的最大管道运行数。

...
spec:
  concurrency_limit: <number>
  ...

如果有多个管道与事件匹配,管道会按照字母顺序与事件启动匹配。

例如,如果您在 .tekton 目录中有三个管道运行,并在存储库配置中创建了一个 concurrency_limit1 的拉取请求,则所有管道运行都会按字母顺序执行。在任意给定时间点,只有一个管道运行处于 running 状态,而其余会处于排队状态。

4.8.12. 使用 Pipelines as Code 解析器

Pipelines as Code 解析器可确保运行的管道运行不会与其他其它运行冲突。

要分割您的管道和管道运行,请将文件存储在 .tekton/ 目录或其子目录中。

如果 Pipelines as Code 在 .tekton/ 目录中的任何 YAML 文件中发现一个带有对任务或管道的引用的管道运行,Pipelines as Code 会自动解析引用的任务,以使用 PipelineRun 对象中嵌入的 spec 提供单个管道运行。

如果 Pipelines as Code 无法解析 PipelinePipelineSpec 定义中引用的任务,则运行会在对集群应用更改前失败。您可以在 Git 供应商平台上查看问题,在 Repository CR 所在的目标命名空间的事件内。

当解析器观察到以下类型的任务时会跳过解析过程:

  • 对一个集群任务的引用。
  • 任务或管道捆绑包。
  • 具有没有 tekton.dev/ 前缀的 API 版本的自定义任务。

解析器以字面形式使用此类任务,不进行任何转换。

如果要在拉取请求中发送它之前在本地对管道运行进行测试,请使用 tkn pac resolve 命令。

您还可以引用远程管道和任务。

4.8.12.1. 在 with Pipelines as Code 中使用远程任务注解

Pipelines as Code 支持在一个管道运行中使用注解来获取远程任务或管道。如果您在管道运行或 PipelineRunPipelineSpec 对象中引用远程任务,Pipelines as Code 码解析器会自动包含它。如果在获取远程任务或解析它们时出现错误,Pipelines as Code 将停止处理任务。

要包含远程任务,请参阅以下注解示例:

引用 Tekton Hub 中的远程任务

  • 在 Tekton Hub 中引用单个远程任务。

    ...
      pipelinesascode.tekton.dev/task: "git-clone" 1
    ...
    1
    Pipelines as Code 包括来自 Tekton Hub 的任务的最新版本。
  • 引用 Tekton Hub 中的多个远程任务

    ...
      pipelinesascode.tekton.dev/task: "[git-clone, golang-test, tkn]"
    ...
  • 使用 -<NUMBER> 后缀引用 Tekton Hub 中的多个远程任务。

    ...
      pipelinesascode.tekton.dev/task: "git-clone"
      pipelinesascode.tekton.dev/task-1: "golang-test"
      pipelinesascode.tekton.dev/task-2: "tkn" 1
    ...
    1
    默认情况下,Pipelines as Code 会将字符串解析为从 Tekton Hub 获取最新的任务。
  • 引用 Tekton Hub 中的远程任务的特定版本。

    ...
      pipelinesascode.tekton.dev/task: "[git-clone:0.1]" 1
    ...
    1
    引用 Tekton Hub 中的 git-clone 远程任务的 0.1 版本。

使用 URL 的远程任务

...
  pipelinesascode.tekton.dev/task: "<https://remote.url/task.yaml>" 1
...

1
远程任务的公共 URL。
注意

从存储库内的 YAML 文件中引用任务

...
pipelinesascode.tekton.dev/task: "<share/tasks/git-clone.yaml>" 1
...

1
到包含任务定义的本地文件的相对路径。

4.8.12.2. 在 Pipelines as Code 中使用远程管道注解

您可以使用远程管道注解在多个存储库间共享管道定义。

...
    pipelinesascode.tekton.dev/pipeline: "<https://git.provider/raw/pipeline.yaml>" 1
...
1
远程管道定义的 URL。您还可以为同一存储库中的文件提供位置。
注意

您只能使用注解引用一个管道定义。

4.8.13. 使用 Pipelines as Code 创建管道运行

要使用 Pipelines as Code 运行管道,您可以在存储库的 .tekton/ 目录中创建管道定义或模板作为 YAML 文件。您可以使用远程 URL 在其他存储库中引用 YAML 文件,但管道运行仅由包含 .tekton/ 目录中的事件触发。

Pipelines as Code 解析器会将所有任务与管道运行绑定,作为一个单独的管道运行,而无需外部依赖项。

注意
  • 对于管道,使用最少一个带有 spec 的管道,或一个独立的 Pipeline 对象。
  • 对于任务,在管道中嵌入任务 spec,或者将其单独定义为一个 Task 对象。

参数化提交和 URL

您可以使用 {{<var>}} 的格式来使用动态的、可扩展的参数,在您的提交中指定参数。目前,您可以使用以下变量:

  • {{repo_owner}}: 存储库所有者。
  • {{repo_name}}: 存储库名称。
  • {{repo_url}}:存储库完整 URL。
  • {{revision}}:提交的完全 SHA 修订。
  • {{sender}}:提交发送者的用户名或帐户 ID。
  • {{source_branch}}:事件源自的分支名称。
  • {{target_branch}}:事件目标的分支名称。对于推送事件,它与 source_branch 相同。
  • {{pull_request_number}}:拉取或合并请求号,仅对 pull_request 事件类型定义。
  • {{git_auth_secret}}:使用 Git 提供程序的令牌自动生成的 secret 名称,用于签出私有存储库。

将事件与管道运行匹配

您可以通过在管道运行中使用特殊注解,将不同的 Git 供应商事件与每个管道匹配。如果有多个管道与事件匹配,Pipelines as Code 会并行运行它们,并在管道运行完成后将结果发送到 Git 供应商。

将 pull 事件与管道运行匹配

您可以使用以下示例将 pipeline-pr-main 管道与以 main 分支为目标的 pull_request 事件匹配:

...
  metadata:
    name: pipeline-pr-main
  annotations:
    pipelinesascode.tekton.dev/on-target-branch: "[main]" 1
    pipelinesascode.tekton.dev/on-event: "[pull_request]"
...
1
您可以通过添加以逗号分隔的条目来指定多个分支。例如:"[main, release-nightly]"。另外,您可以指定以下内容:
  • 对分支的完整引用,如 "refs/heads/main"
  • 带有模式匹配的 globs,如 "refs/heads/\ the"
  • 标签,如 "refs/tags/1.\*"

将推送事件与管道运行匹配

您可以使用以下示例将 pipeline-push-on-main 管道与以 refs/heads/main 分支为目标的 push 事件匹配:

...
  metadata:
    name: pipeline-push-on-main
  annotations:
    pipelinesascode.tekton.dev/on-target-branch: "[refs/heads/main]" 1
    pipelinesascode.tekton.dev/on-event: "[push]"
...
1
您可以通过添加以逗号分隔的条目来指定多个分支。例如:"[main, release-nightly]"。另外,您可以指定以下内容:
  • 对分支的完整引用,如 "refs/heads/main"
  • 带有模式匹配的 globs,如 "refs/heads/\ the"
  • 标签,如 "refs/tags/1.\*"

高级事件匹配

Pipelines as Code 支持在高级事件匹配中使用基于通用表达式语言 (CEL) 的过滤。如果您在管道运行中有 pipelinesascode.tekton.dev/on-cel-expression 注解,PPipelines as Code 使用 CEL 表达式并跳过 on-target-branch 注解。与简单的 on-target-branch 注解匹配相比,CEL 表达式允许复杂的过滤和负效果。

要将基于 CEL 的过滤作为代码使用,请考虑以下注解示例:

  • 匹配以 main 分支为目标并来自 wip 分支的 pull_request 事件:

    ...
      pipelinesascode.tekton.dev/on-cel-expression: |
        event == "pull_request" && target_branch == "main" && source_branch == "wip"
    ...
  • 要仅在路径更改时运行管道,您可以使用带有 glob 模式的 .pathChanged 后缀功能:

    ...
      pipelinesascode.tekton.dev/on-cel-expression: |
        event == "pull_request" && "docs/\*.md".pathChanged() 1
    ...
    1
    匹配 docs 目录中的所有 markdown 文件。
  • 匹配以标题 [DOWNSTREAM] 开头的所有拉取请求:

    ...
      pipelinesascode.tekton.dev/on-cel-expression: |
        event == "pull_request && event_title.startsWith("[DOWNSTREAM]")
    ...
  • 要在 pull_request 事件上运行管道,但跳过 experimental 分支:

    ...
      pipelinesascode.tekton.dev/on-cel-expression: |
        event == "pull_request" && target_branch != experimental"
    ...

对于使用 Pipelines as Code 时进行基于 CEL 的高级过滤,您可以使用以下字段和后缀功能:

  • event: 一个 pushpull_request 事件。
  • target_branch:目标分支。
  • source_branch: 一个 pull_request 事件的源分支。对于 push 事件,它与 target_branch 相同。
  • event_title :匹配事件的标题,如一个 push 事件的提交标题,以及 pull_request 事件的 pull 或 merge 请求的标题。目前,只有 GitHub、Gitlab 和 Bitbucket 云是受支持的提供程序。
  • .pathChanged:字符串的后缀函数。如果路径已改变,字符串可以是一个路径的 glob。目前,只支持 GitHub 和 Gitlab。

使用临时 GitHub App 令牌用于 Github API 操作

您可以使用来自 GitHub App 的 Pipelines as Code 生成的临时安装令牌来访问 GitHub API。令牌值存储在为私有存储库生成的临时 {{git_auth_secret}} 动态变量的 git-provider-token 键中。

例如,要在拉取请求中添加注释,您可以使用 Tekton Hub 中的 github-add-comment 任务使用 Pipelines as Code 注解:

...
  pipelinesascode.tekton.dev/task: "github-add-comment"
...

然后,您可以在 tasks 部分添加任务,或管道运行定义中的 finally 任务:

[...]
tasks:
  - name:
      taskRef:
        name: github-add-comment
      params:
        - name: REQUEST_URL
          value: "{{ repo_url }}/pull/{{ pull_request_number }}" 1
        - name: COMMENT_OR_FILE
          value: "Pipelines as Code IS GREAT!"
        - name: GITHUB_TOKEN_SECRET_NAME
          value: "{{ git_auth_secret }}"
        - name: GITHUB_TOKEN_SECRET_KEY
          value: "git-provider-token"
...
1
通过使用动态变量,您可以为来自任何存储库的任何拉取请求重复使用此片断模板。
注意

在 GitHub 应用程序中,生成的安装令牌的有效期为 8 小时,其范围限制于事件源自于集群中配置的存储库。

其他资源

4.8.14. 使用 Pipelines as Code 运行管道运行

使用默认配置,当指定事件(如拉取请求或推送在仓库上发生)时,Pipelines as Code 会在默认分支的 .tekton/ 目录中运行任何管道运行。例如,如果在默认分支上运行的管道具有注解 pipelinesascode.tekton.dev/on-event: "[pull_request]",它将在每次发生拉取请求事件时运行。

如果是拉取请求或合并请求,Pipelines as Code 也会从默认分支以外的分支运行管道,如果拉取请求作者满足以下条件:

  • 作者是存储库的所有者。
  • 作者是存储库的合作者。
  • 作者是存储库机构中的公共成员。
  • 拉取请求作者列在位于 main 分支存储库根的 OWNER 文件中,如存储库的 GitHub 配置中定义的。另外,拉取请求作者被添加到 approversreviewers 部分。例如,如果作者在 approvers 部分中列出,则作者引发的拉取请求将启动管道运行。
...
  approvers:
    - approved
...

如果拉取请求作者没有满足要求,则满足要求的其他用户可以在拉取请求中注释掉 /ok-to-test,并启动管道运行。

Pipeline 运行执行

管道运行始终在与生成事件的存储库关联的 Repository CRD 的命名空间中运行。

您可以使用 tkn pac CLI 工具观察管道运行的执行。

  • 要遵循最后一次管道运行的执行,请使用以下示例:

    $ tkn pac logs -n <my-pipeline-ci> -L 1
    1
    my-pipeline-ciRepository CRD 的命名空间。
  • 要以交互方式执行任何管道运行,请使用以下示例:

    $ tkn pac logs -n <my-pipeline-ci> 1
    1
    my-pipeline-ciRepository CRD 的命名空间。如果需要查看除最后一个管道运行以外的管道运行,您可以使用 tkn pac logs 命令选择附加到仓库的 PipelineRun

如果您配置使用 GitHub App 的 Pipelines as Code,Pipelines as Code 会在 GitHub App 的 Checks 选项卡中发布了一个 URL。您可以点 URL 并按照管道执行进行操作。

重启管道运行

您可以重启没有事件的管道运行,如向分支发送新提交或提升拉取请求。在 GitHub App 上,进入 Checks 选项卡,然后点 Re-run

如果您以 pull 或 merge 请求为目标,请在拉取请求中使用以下注释来重启所有或特定的管道运行:

  • /retest 注释会重启所有管道运行。
  • /retest <pipelinerun-name> 注释重启特定的管道运行。
  • /cancel 注释取消所有管道运行。
  • /cancel <pipelinerun-name> 注释会取消特定的管道运行。

注释的结果在 GitHub App 的 Checks 选项卡中显示。

4.8.15. 使用 Pipelines as Code 监控管道运行状态

根据上下文和支持的工具,您可以以不同的方式监控管道运行的状态。

GitHub 应用程序的状态

当管道运行完成后,在 Check 选项卡中添加状态,其中包含管道的每个任务以及 tkn pipelinerun describe 命令的输出的有限信息。

日志错误片断

当 Pipelines as Code 检测到管道其中一个任务中的错误时,会显示一段信息,它包括第一个失败的任务的任务详情中的最后 3 行信息。

注意

Pipelines as Code 通过查看管道运行并使用隐藏字符替换 secret 值来避免泄漏 secret。但是,Pipelines as Code 无法隐藏来自工作区和 envFrom 源的 secret。

日志错误片断的注解

在 Pipelines as Code 配置映射中,如果您将 error-detection-from-container-logs 参数设置为 true,Pipelines as Code 会检测容器日志中的错误,并在发生错误的拉取请求中添加它们作为注解。

重要

这个功能只是一个技术预览。

目前,Pipelines as Code 只支持使用以下格式的 makefilegrep 输出的简单情况:

<filename>:<line>:<column>: <error message>

您可以使用 error-detection-simple-regexp 字段自定义用于检测错误的正则表达式。正则表达式使用命名组来授予如何指定匹配的灵活性。需要匹配的组包括文件名、行和错误。您可以查看 Pipelines as Code 配置映射用于默认正则表达式。

注意

默认情况下,Pipelines as Code 只扫描容器日志的最后 50 行。您可以在 error-detection-max-number-of-lines 字段中增加这个值,或为无限数量的行设置 -1。但是,此类配置可能会增加监视器的内存用量。

Webhook 的状态

对于 Webhook,当事件是拉取请求时,状态将添加为拉取请求或合并请求的注释。

失败

如果命名空间与 Repository CRD 匹配,Pipelines as Code 会在命名空间中的 Kubernetes 事件中发出其失败日志消息。

与 Repository CRD 关联的状态

管道运行的最后 5 个状态消息存储在 Repository 自定义资源中。

$ oc get repo -n <pipelines-as-code-ci>
NAME                  URL                                                        NAMESPACE             SUCCEEDED   REASON      STARTTIME   COMPLETIONTIME
pipelines-as-code-ci   https://github.com/openshift-pipelines/pipelines-as-code   pipelines-as-code-ci   True        Succeeded   59m         56m

使用 tkn pac describe 命令,您可以提取与存储库及其元数据关联的运行状态。

通知

Pipelines as Code 不管理通知。如果您需要通知,请使用管道的 finally 功能。

4.8.16. 在 Pipelines as Code 中使用私有存储库

Pipelines as Code 通过使用用户令牌在目标命名空间中创建或更新 secret 来支持私有存储库。Tekton Hub 中的 git-clone 任务使用用户令牌来克隆私有存储库。

每当作为代码在目标命名空间中运行时,它会使用 pac-gitauth-<REPOSITORY_OWNER>-<REPOSITORY_NAME>-<RANDOM_STRING> 格式创建或更新 secret。

您必须使用管道运行和管道定义中的 basic-auth 工作区来引用 secret,然后传递给 git-clone 任务。

...
  workspace:
  - name: basic-auth
    secret:
      secretName: "{{ git_auth_secret }}"
...

在管道中,您可以引用 git-clone 任务的 basic-auth 工作区来重复使用:

...
workspaces:
  - name basic-auth
params:
    - name: repo_url
    - name: revision
...
tasks:
  workspaces:
    - name: basic-auth
      workspace: basic-auth
  ...
  tasks:
  - name: git-clone-from-catalog
      taskRef:
        name: git-clone 1
      params:
        - name: url
          value: $(params.repo_url)
        - name: revision
          value: $(params.revision)
...
1
git-clone 任务获取 basic-auth 工作区,并使用它来克隆私有存储库。

根据 Pipelines as Code 配置映射中的要求,您可以通过将 secret-auto-create 标志设置为 falsetrue 值来修改此配置。

4.8.17. 使用 Pipelines as Code 清理管道运行

在一个用户命名空间中可以运行多个管道。通过设置 max-keep-runs 注解,您可以将 Pipelines as Code 配置为保留与事件匹配的有限数量的管道运行。例如:

...
  pipelinesascode.tekton.dev/max-keep-runs: "<max_number>" 1
...
1
Pipelines as Code 在成功完成执行后启动清理,只保留使用注解配置的最大管道运行数量。
注意
  • Pipelines as Code 会跳过清理运行的管道,但会清理带有未知状态的管道运行。
  • Pipelines as Code 会跳过清理失败的拉取请求。

4.8.18. 在 Pipelines as Code 中使用传人(incoming)webhook

使用传入的 webhook URL 和共享 secret,您可以在存储库中启动管道运行。

要使用传入的 Webhook,请在 Repository CRD 的 spec 部分指定以下内容:

  • Pipelines as Code 匹配的传入 Webhook URL。
  • Git 提供程序和用户令牌。目前,Pipelines as Code 支持 githubgitlabbitbucket-cloud

    注意

    在 GitHub 应用程序上下文中使用传入的 Webhook URL 时,您必须指定令牌。

  • 目标分支和传入 Webhook URL 的 secret。

示例: 带有传入 Webhook 的 Repository CRD

apiVersion: "pipelinesascode.tekton.dev/v1alpha1"
kind: Repository
metadata:
  name: repo
  namespace: ns
spec:
  url: "https://github.com/owner/repo"
  git_provider:
    type: github
    secret:
      name: "owner-token"
  incoming:
    - targets:
      - main
      secret:
        name: repo-incoming-secret
      type: webhook-url

示例:传入 webhook 的 repo-incoming-secret secret

apiVersion: v1
kind: Secret
metadata:
  name: repo-incoming-secret
  namespace: ns
type: Opaque
stringData:
  secret: <very-secure-shared-secret>

要触发位于 Git 存储库的 .tekton 目录中的管道运行,请使用以下命令:

$ curl -X POST 'https://control.pac.url/incoming?secret=very-secure-shared-secret&repository=repo&branch=main&pipelinerun=target_pipelinerun'

Pipelines as Code 与传入的 URL 匹配,并将其视为 push 事件。但是,Pipelines as Code 不会报告这个命令触发的管道运行的状态。

要获取报告或通知,请将 finally 任务直接添加到您的管道中。另外,您可以使用 tkn pac CLI 工具检查 Repository CRD。

4.8.19. 自定义 Pipelines as Code 配置

要自定义 Pipelines as Code,集群管理员可使用 pipelines-as-code 命名空间中的 pipelines-as-code 配置映射配置以下参数:

表 4.8. 自定义 Pipelines as Code 配置
参数描述default

application-name

应用程序的名称。例如,GitHub Checks 标签中显示的名称。

"Pipelines as Code CI"

max-keep-days

执行的管道运行的天数保存在 pipelines-as-code 命名空间中。

请注意,此配置映射设置不会影响用户的管道运行的清理,这由用户 GitHub 仓库中管道运行定义上的注解控制。

 

secret-auto-create

指明是否应使用 GitHub 应用中生成的令牌自动创建 secret。然后可将这个 secret 用于私有仓库。

enabled

remote-tasks

启用后,允许来自管道运行注解的远程任务。

enabled

hub-url

Tekton Hub API 的基本 URL。

https://hub.tekton.dev/

hub-catalog-name

Tekton Hub 目录名称。

tekton

tekton-dashboard-url

Tekton Hub 仪表板的 URL。Pipelines as Code 使用这个 URL 在 Tekton Hub 仪表板中生成一个 PipelineRun URL。

不适用

bitbucket-cloud-check-source-ip

通过查询公共 Bitbucket 的 IP 范围来指示是否保护服务请求。更改参数的默认值可能会导致安全问题。

enabled

bitbucket-cloud-additional-source-ip

指明是否提供一组额外的 IP 范围或网络,它们用逗号分开。

不适用

max-keep-run-upper-limit

管道运行的 max-keep-run 值的最大值。

不适用

default-max-keep-runs

管道运行的 max-keep-run 值的默认限制。如果定义,该值将应用到没有 max-keep-run 注解的所有管道运行。

不适用

auto-configure-new-github-repo

自动配置新的 GitHub 存储库。Pipelines as Code 设置命名空间,并为存储库创建一个自定义资源。这个参数只支持 GitHub 应用程序。

disabled

auto-configure-repo-namespace-template

如果启用了 auto-configure-new-github-repo,将模板配置为为新仓库自动生成命名空间。

{repo_name}-pipelines

error-log-snippet

启用或禁用失败任务的日志片断视图,管道中有一个错误。当管道的数据泄漏时,您可以禁用此参数。

enabled

4.8.20. Pipelines as Code 命令参考

tkn pac CLI 工具提供以下功能:

  • Bootstrap Pipelines as Code 安装和配置。figuration.
  • 创建一个新的 Pipelines as Code 仓库。
  • 列出所有 Pipelines as Code 仓库。
  • 描述一个 Pipelines as Code 仓库和相关联的运行。
  • 生成简单的管道运行以开始。
  • 如由 Pipelines as Code 执行来解析一个管道运行。
提示

您可以使用与功能对应的命令进行测试和试验,因此您不必对包含应用源代码的 Git 仓库进行更改。

4.8.20.1. 基本语法

$ tkn pac [command or options] [arguments]

4.8.20.2. 全局选项

$ tkn pac --help

4.8.20.3. 工具命令

4.8.20.3.1. bootstrap
表 4.9. 将管道作为代码安装和配置引导
命令描述

tkn pac bootstrap

安装并配置 Pipelines 作为 Git 仓库托管服务提供商的 Code,如 GitHub 和 GitHub Enterprise。

tkn pac bootstrap --nightly

安装每天(nightly)构建的 Pipelines as Code。

tkn pac bootstrap --route-url <public_url_to_ingress_spec>

覆盖 OpenShift 路由 URL。

默认情况下,tkn pac bootstrap 会检测 OpenShift 路由,该路由会自动与 Pipelines as Code 控制器服务关联。

如果您没有 OpenShift Container Platform 集群,它会要求您输入指向入口端点的公共 URL。

tkn pac bootstrap github-app

pipelines-as-code 命名空间中创建 GitHub 应用程序和 secret。

4.8.20.3.2. 软件仓库
表 4.10. 管理 Pipelines 作为代码软件仓库
命令描述

tkn pac repo create

根据管道运行模板创建一个新的 Pipelines as Code 仓库以及一个命名空间。

tkn pac repo list

列出所有 Pipelines as Code 软件仓库,并显示关联运行的最后一个状态。

tkn pac repo describe

描述一个 Pipelines as Code 仓库和相关联的运行。

4.8.20.3.3. generate
表 4.11. 使用 Pipelines as Code 创建管道运行
命令描述

tkn pac generate

生成简单的管道运行。

从包含源代码的目录执行时,它会自动检测当前的 Git 信息。

另外,它使用基本的语言检测功能,并根据语言添加额外的任务。

例如,如果它在仓库的 root 中检测到一个 setup.py 文件,则 pylint 任务会自动添加到生成的管道运行中。

4.8.20.3.4. 解析
表 4.12. 使用 Pipelines as Code 解析并执行管道运行
命令描述

tkn pac resolve

执行管道运行,就像由 Pipelines as Code 服务中所有的一样。

tkn pac resolve -f .tekton/pull-request.yaml | oc apply -f -

显示在 .tekton/pull-request.yaml 中使用模板的实时管道运行状态。

结合在本地机器上运行的 Kubernetes 安装,您可以在不生成新提交的情况下观察管道运行。

如果从源代码存储库运行命令,它会尝试检测当前的 Git 信息并自动解析当前修订或分支等参数。

tkn pac resolve -f .tekton/pr.yaml -p revision=main -p repo_name=<repository_name>

通过覆盖从 Git 存储库派生的默认参数值来执行管道运行。

-f 选项也可以接受目录路径,并在该目录中的所有 .yaml.yml 文件中应用 tkn pac resolve 命令。您还可以在同一命令中多次使用 -f 标志。

您可以使用 -p 选项指定参数值,覆盖 Git 仓库收集的默认信息。例如,您可以使用 Git 分支作为修订和不同的仓库名称。

4.8.21. 其他资源

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

© 2024 Red Hat, Inc.