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 pac
和 opc
CLI 工具,或作为容器进行测试。当您为 Red Hat OpenShift Pipelines 安装 tkn
CLI 时,tkn pac
和 opc
CLI 工具会自动安装。
您可以为支持的平台安装 tkn pac
和 opc
版本 1.9.1
二进制文件:
- Linux (x86_64, amd64)
- Linux on IBM Z and LinuxONE (s390x)
- Linux on IBM Power Systems (ppc64le)
- Mac
- 注意
二进制文件与
tkn
版本0.23.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 应用程序,请执行以下步骤:
- 登录您的 GitHub 帐户。
-
进入 Settings
Developer settings GitHub Apps,然后点 New GitHub App。 在 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。
-
GitHub 应用程序名称:
选择以下仓库权限 :
-
Checks:
Read & Write
-
Contents:
Read & Write
-
Issues:
Read & Write
-
Metadata:
Read-only
-
Pull request:
Read & Write
-
Checks:
选择以下机构权限 :
-
Members:
Readonly
-
Plan:
Readonly
-
Members:
选择以下用户权限 :
- Commit comment
- Issue comment
- Pull request
- Pull request review
- Pull request review comment
- push
- 点 Create GitHub App。
- 在新创建的 GitHub App 的 Details 页面中,记录顶部显示的 App ID。
- 在 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
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。
流程
- 在 Administrator 视角中,使用导航窗格进入到 Pipelines。
- 在 Pipelines 页面中点 Setup GitHub App。
-
输入您的 GitHub 应用程序名称。例如,
pipelines-ci-clustername-testui
。 - 点 Setup。
- 在浏览器中提示时输入您的 Git 密码。
-
点 Create GitHub App for <username>,其中
<username>
是您的 GitHub 的用户名。
验证
成功创建 GitHub 应用程序后,OpenShift Container Platform Web 控制台会打开并显示应用程序的详情。
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
范围。
流程
配置 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,请执行以下步骤:在 OpenShift 集群中,提取 Pipelines as Code 控制器的公共 URL。
$ echo https://$(oc get route -n pipelines-as-code pipelines-as-code-controller -o jsonpath='{.spec.host}')
在 GitHub 存储库或机构中执行以下步骤:
- 进入 Settings -> Webhooks 并点 Add webhook。
- 将 Payload URL 设置为 Pipelines as Code 的公共 URL。
- 将内容类型选为 application/json。
添加 webhook secret 并在另一个位置记录它。在本地机器上安装
openssl
后,生成一个随机 secret。$ openssl rand -hex 20
- 点 Let me select individual events 并选择这些事件:Commit comments, Issue comments, Pull request, 和 Pushes.
- 点击 Add webhook。
在 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>"
创建
Repository
CR。示例:
Repository
CRapiVersion: "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 位于同一命名空间中。
可选: 对于现有的
Repository
CR,请添加多个 GitHub Webhook secret 或为已删除的 secret 提供替换。使用
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.
-
更新现有 OpenShift
Secret
对象中的webhook.secret
密钥。
可选: 对于现有的
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 来更新个人访问令牌。在
Repository
CR 中查找 secret 的名称。... spec: git_provider: secret: name: "github-webhook-config" ...
使用
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 评论的方式显示结果。
-
如果要使用
流程
配置 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,请执行以下步骤:在 OpenShift 集群中,提取 Pipelines as Code 控制器的公共 URL。
$ echo https://$(oc get route -n pipelines-as-code pipelines-as-code-controller -o jsonpath='{.spec.host}')
在 GitLab 项目中,执行以下步骤:
- 使用左侧边栏进入 Settings -> Webhooks。
- 将 URL 设置为 Pipelines as Code 控制器公共 URL。
添加 webhook secret 并在另一个位置记录它。在本地机器上安装
openssl
后,生成一个随机 secret。$ openssl rand -hex 20
- 点 Let me select individual events 并选择这些事件:Commit comments, Issue comments, Pull request, 和 Pushes.
- 点 Save Changes。
在 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>"
创建
Repository
CR。示例:
Repository
CRapiVersion: "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 位于同一命名空间中。
可选: 对于现有的
Repository
CR,请添加多个 GitLab Webhook secret 或为已删除的 secret 提供替换。使用
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.
-
更新现有 OpenShift
Secret
对象中的webhook.secret
密钥。
可选: 对于现有的
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 来更新个人访问令牌。在
Repository
CR 中查找 secret 的名称。... spec: git_provider: secret: name: "gitlab-webhook-config" ...
使用
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
-
工作区成员资格:
Read
、Write
-
项目:
Read
,Write
-
Issues:
Read
,Write
Pull requests:
Read
,Write
注意-
如果要使用
tkn pac
CLI 配置 webhook,请在令牌中添加Webhooks
:Read
和Write
权限。 - 生成后,在另外一个位置保持密码或令牌的副本。
-
如果要使用
-
账户:
流程
配置 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,请执行以下步骤:在 OpenShift 集群中,提取 Pipelines as Code 控制器的公共 URL。
$ echo https://$(oc get route -n pipelines-as-code pipelines-as-code-controller -o jsonpath='{.spec.host}')
在 Bitbucket Cloud 上,执行以下步骤:
- 使用 Bitbucket Cloud 存储库的左侧导航窗格,进入 Repository settings -> Webhooks,然后点 Add webhook。
- 设置 Title。例如,"Pipelines as Code"。
- 将 URL 设置为 Pipelines as Code 控制器公共 URL。
- 选择这些事件: Repository: Push,Pull Request: Created,Pull Request: Updated, 和 Pull Request: Comment created.
- 点击 Save。
在 OpenShift 集群中,使用目标命名空间中的 app 密码创建一个
Secret
对象。$ oc -n target-namespace create secret generic bitbucket-cloud-token \ --from-literal provider.token="<BITBUCKET_APP_PASSWORD>"
创建
Repository
CR。示例:
Repository
CRapiVersion: "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
注意-
Bitbucket 云不支持
tkn pac create
和tkn 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
命名空间的代码配置映射。
-
要禁用这个默认行为,在 Pipelines 中将
可选: 对于现有的
Repository
CR,请添加多个 Bitbucket Cloud Webhook secret 或为已删除的 secret 提供替换。使用
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>]
选项。-
更新现有 OpenShift
Secret
对象中的webhook.secret
密钥。
可选: 对于现有的
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 来更新个人访问令牌。在
Repository
CR 中查找 secret 的名称。... spec: git_provider: user: "<BITBUCKET_USERNAME>" secret: name: "bitbucket-cloud-token" key: "provider.token" ...
使用
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_ADMIN
和REPOSITORY_ADMIN
权限。 - 令牌必须有权访问拉取请求中分叉的存储库。
-
令牌必须具有
流程
在 OpenShift 集群中,提取 Pipelines as Code 控制器的公共 URL。
$ echo https://$(oc get route -n pipelines-as-code pipelines-as-code-controller -o jsonpath='{.spec.host}')
在 Bitbucket 服务器上,执行以下步骤:
- 使用 Bitbucket Data Center 存储库的左侧导航窗格,进入 Repository settings -> Webhooks 并点 Add webhook。
- 设置 Title。例如,"Pipelines as Code"。
- 将 URL 设置为 Pipelines as Code 控制器公共 URL。
添加 webhook secret,并将它的副本保存到备用位置。如果您在本地机器上安装了
openssl
,使用以下命令生成随机 secret:$ openssl rand -hex 20
选择以下事件:
- Repository: Push
- Repository: Modified
- Pull Request: Opened
- Pull Request: Source branch updated
- Pull Request: Comment added
- 点击 Save。
在 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>"
创建
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
注意Bitbucket 服务器不支持
tkn pac create
和tkn 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_limit
为 1
的拉取请求,则所有管道运行都会按字母顺序执行。在任意给定时间点,只有一个管道运行处于 running 状态,而其余会处于排队状态。
4.8.12. 使用 Pipelines as Code 解析器
Pipelines as Code 解析器可确保运行的管道运行不会与其他其它运行冲突。
要分割您的管道和管道运行,请将文件存储在 .tekton/
目录或其子目录中。
如果 Pipelines as Code 在 .tekton/
目录中的任何 YAML 文件中发现一个带有对任务或管道的引用的管道运行,Pipelines as Code 会自动解析引用的任务,以使用 PipelineRun
对象中嵌入的 spec 提供单个管道运行。
如果 Pipelines as Code 无法解析 Pipeline
或 PipelineSpec
定义中引用的任务,则运行会在对集群应用更改前失败。您可以在 Git 供应商平台上查看问题,在 Repository
CR 所在的目标命名空间的事件内。
当解析器观察到以下类型的任务时会跳过解析过程:
- 对一个集群任务的引用。
- 任务或管道捆绑包。
-
具有没有
tekton.dev/
前缀的 API 版本的自定义任务。
解析器以字面形式使用此类任务,不进行任何转换。
如果要在拉取请求中发送它之前在本地对管道运行进行测试,请使用 tkn pac resolve
命令。
您还可以引用远程管道和任务。
4.8.12.1. 在 with Pipelines as Code 中使用远程任务注解
Pipelines as Code 支持在一个管道运行中使用注解来获取远程任务或管道。如果您在管道运行或 PipelineRun
或 PipelineSpec
对象中引用远程任务,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。注意
如果使用 GitHub,远程任务 URL 使用与
Repository
CRD 相同的主机,Pipelines as Code 会使用 GitHub 令牌并使用 GitHub API 获取 URL。例如,您有一个类似
https://github.com/<organization>/<repository>
的存储库 URL,远程 HTTP URL 引用一个与https://github.com/<organization>/<repository>/blob/<mainbranch>/<path>/<file>
类似的 GitHub blob,Pipelines as Code 会使用 GitHub App 令牌从私有存储库中抓取任务定义。当您使用公共 GitHub 存储库时,Pipelines as Code 的行为与 GitHub 原始 URL(如
https://raw.githubusercontent.com/<organization>/<repository>/<mainbranch>/<path>/<file>
)类似。- GitHub App 令牌的范围为所有者或存储库所在的机构。使用 GitHub Webhook 方法时,您可以在允许个人令牌的任何机构中获取任何私有或公共存储库。
从存储库内的 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
: 一个push
或pull_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 配置中定义的。另外,拉取请求作者被添加到approvers
或reviewers
部分。例如,如果作者在approvers
部分中列出,则作者引发的拉取请求将启动管道运行。
... approvers: - approved ...
如果拉取请求作者没有满足要求,则满足要求的其他用户可以在拉取请求中注释掉 /ok-to-test
,并启动管道运行。
Pipeline 运行执行
管道运行始终在与生成事件的存储库关联的 Repository
CRD 的命名空间中运行。
您可以使用 tkn pac
CLI 工具观察管道运行的执行。
如果您配置使用 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 只支持使用以下格式的 makefile
或 grep
输出的简单情况:
<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
标志设置为 false
或 true
值来修改此配置。
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 支持
github
、gitlab
和bitbucket-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
配置映射配置以下参数:
参数 | 描述 | default |
---|---|---|
| 应用程序的名称。例如,GitHub Checks 标签中显示的名称。 |
|
|
执行的管道运行的天数保存在 请注意,此配置映射设置不会影响用户的管道运行的清理,这由用户 GitHub 仓库中管道运行定义上的注解控制。 | |
| 指明是否应使用 GitHub 应用中生成的令牌自动创建 secret。然后可将这个 secret 用于私有仓库。 |
|
| 启用后,允许来自管道运行注解的远程任务。 |
|
| Tekton Hub API 的基本 URL。 | |
| Tekton Hub 目录名称。 |
|
|
Tekton Hub 仪表板的 URL。Pipelines as Code 使用这个 URL 在 Tekton Hub 仪表板中生成一个 | 不适用 |
| 通过查询公共 Bitbucket 的 IP 范围来指示是否保护服务请求。更改参数的默认值可能会导致安全问题。 |
|
| 指明是否提供一组额外的 IP 范围或网络,它们用逗号分开。 | 不适用 |
|
管道运行的 | 不适用 |
|
管道运行的 | 不适用 |
| 自动配置新的 GitHub 存储库。Pipelines as Code 设置命名空间,并为存储库创建一个自定义资源。这个参数只支持 GitHub 应用程序。 |
|
|
如果启用了 |
|
| 启用或禁用失败任务的日志片断视图,管道中有一个错误。当管道的数据泄漏时,您可以禁用此参数。 |
|
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
命令 | 描述 |
---|---|
| 安装并配置 Pipelines 作为 Git 仓库托管服务提供商的 Code,如 GitHub 和 GitHub Enterprise。 |
| 安装每天(nightly)构建的 Pipelines as Code。 |
| 覆盖 OpenShift 路由 URL。
默认情况下, 如果您没有 OpenShift Container Platform 集群,它会要求您输入指向入口端点的公共 URL。 |
|
在 |
4.8.20.3.2. 软件仓库
命令 | 描述 |
---|---|
| 根据管道运行模板创建一个新的 Pipelines as Code 仓库以及一个命名空间。 |
| 列出所有 Pipelines as Code 软件仓库,并显示关联运行的最后一个状态。 |
| 描述一个 Pipelines as Code 仓库和相关联的运行。 |
4.8.20.3.3. generate
命令 | 描述 |
---|---|
| 生成简单的管道运行。 从包含源代码的目录执行时,它会自动检测当前的 Git 信息。 另外,它使用基本的语言检测功能,并根据语言添加额外的任务。
例如,如果它在仓库的 root 中检测到一个 |
4.8.20.3.4. 解析
命令 | 描述 |
---|---|
| 执行管道运行,就像由 Pipelines as Code 服务中所有的一样。 |
|
显示在 结合在本地机器上运行的 Kubernetes 安装,您可以在不生成新提交的情况下观察管道运行。 如果从源代码存储库运行命令,它会尝试检测当前的 Git 信息并自动解析当前修订或分支等参数。 |
| 通过覆盖从 Git 存储库派生的默认参数值来执行管道运行。
您可以使用 |