我已创建工具链，但 Delivery Pipeline 服务未初始化。 为什么管道初始化未完成?

您可能需要再次配置并保存 GitHub 工具集成。

工具链中的 GitHub 工具集成可能配置错误，这将阻止管道初始化完成。

发生了事件问题，导致 GitHub 工具集成失败。

再次配置并保存 GitHub 工具集成:

1. 在 IBM Cloud 控制台中，单击菜单图标 > 平台自动化 > 工具链。 在“工具链”页面，单击您创建的工具链，打开“概览”页面。 或者，在应用程序的“应用程序详细信息”页面上，单击工具链名称。
2. 在“工具链的概述”页面上的 存储库 卡上，找到 GitHub 工具集成。
3. 单击菜单以访问配置选项，更新设置，然后单击 保存集成。
4. 在 交付管道 卡上，单击 Delivery Pipeline 工具集成以查看管道设置。

通过我编写的模板创建工具链时，为什么管道没有正确创建？

由于 pipeline.yaml 定义中有错误，管道可能缺少作业和阶段等资源。

我尝试通过编写的模板创建工具链时，在“管道”页面上收到以下错误消息：

This pipeline was created, but might be missing jobs, stages, or other resources. You can use this pipeline, or if you prefer, you can delete it and create another pipeline.

通常，导致此问题的原因是 pipeline.yaml 定义中有错误。

可以使用以下任一方法来调试此错误：

• 使用管道用户界面来创建示例管道，该管道将复制您尝试使用模板构建的管道。 将 /yaml 附加到管道 URL 以生成类似的 pipeline.yaml 文件，您可以使用该文件来查找明显的差异。 例如，https://cloud.ibm.com/devops/pipelines/<your pipeline id>/yaml?env_id=<your region>。

• 使用无头工具链创建机制。 在创建工具链页面上，打开调试器并对 window.Testflags = {nocreate: 1} 表达式求值。 在此方式下单击创建工具链时，不会创建工具链。 系统会改为将传递给 API 的信息返回到控制台，供您在其中复查这些信息。

我尝试运行管道，为什么收到有关访问 Git 存储库 (存储库) 的错误?

管道使用访问令牌来克隆 Git 存储库。 如果此访问令牌无效，那么 Git 集成的所有者无法访问 Git 存储库。

支持的 Git 集成包括 GitHub, GitLab, Bitbucket 或 Git Repos and Issue Tracking工具集成。

尝试运行管道时，收到以下错误消息:

The access token for this git repository is no longer valid. Please reconfigure the git integration to ensure the integration owner has access to this repository.

管道用于克隆 Git 存储库的访问令牌不再有效。 可能会发生此问题，因为令牌已失效。 如果 Git 集成的所有者由于许可权更改而失去对存储库的访问权，那么访问令牌也可能无效。

再次配置并保存 Git 集成:

1. 在 IBM Cloud 控制台中，单击菜单图标 > 平台自动化 > 工具链。 在“工具链”页面，点击包含要更新的Git集成的工具链，打开“概述”页面。 或者，在应用程序的“应用程序详细信息”页面上，单击工具链名称。
2. 在“工具链的概述”页面上的 存储库 卡上，找到 Git 工具集成。
3. 单击菜单以访问配置选项，选择 Git 集成所有者的授权 Git 帐户，然后单击 保存集成。
4. 再次运行管道。

我尝试使用 Delivery Pipeline 将数据部署到 Kubernetes，为什么会出现对象无效的错误？

1.0 管道基本映像包含 kubectl V1.14.2。 如果要连接到的 Kubernetes 集群运行的是更新版本的 Kubernetes，那么可能会收到错误。

我尝试使用 Delivery Pipeline 部署到 Kubernetes 时，收到以下错误消息：

error:SchemaeError(io.k8s.api.core.v1.SecretProjection): invalid object doesn't have additional properties

通常，管道基本映像中 kubectl 命令的版本与集群中运行的 Kubernetes 版本不兼容时，会导致此问题。

可以使用以下任一方法来解决此问题：

• 使用更新的管道基本映像版本，映像在创建时包含当前发布的 kubectl 版本。 有关如何指定最新映像版本的信息，请参阅指定映像版本。

• 确保管道作业运行的是正确版本的 kubectl。 例如，将以下行添加到管道作业的开头以运行 kubectl V1.14.2：

  curl -LO https://storage.googleapis.com/kubernetes-release/release/v1.14.2/bin/linux/amd64/kubectl
  chmod +x ./kubectl
  sudo mv ./kubectl /usr/local/bin/kubectl

如果是从 1.0 管道基本映像运行 kubectl V1.14.2，那么 sudo 选项不可用。 请将 sudo 行替换为以下命令，以将 kubectl 添加到路径：

   mkdir ~/.bin && export PATH=~/.bin:$PATH && mv ./kubectl ~/.bin/kubectl

有关访问所需 kubectl 准确版本的更多信息，请参阅 安装和设置 kubectl。

我尝试运行管道，为何从 IBM Cloud Container Registry获取 403 错误?

IBM Cloud® Container Registry 管道将图像推送到 IBM Cloud Container Registry 并从中拉取图像。 IBM Cloud Container Registry 服务计划决定了您可用于私人图像的存储量和拉取流量。

尝试运行管道时，收到以下错误消息:

Failed to pull image "us.icr.io/sdl-ns/achilles:a100-p203-6-20190717161046-78fbc8a3a0fbc8571d887e57499642e0326e7035": rpc error: code = Unknown desc = failed to pull and unpack image "us.icr.io/sdl-ns/achilles:a100-p203-6-20190717161046-78fbc8a3a0fbc8571d887e57499642e0326e7035": failed to copy: httpReaderSeeker: failed open: unexpected status code https://us.icr.io/v2/sdl-ns/achilles/blobs/sha256:365b19774a508fd998bc636981cb9869a406786ad811e51937fa6fb089c86005: 403 Forbidden

您可能已超过 拉取流量配额限制，这将阻止访存 Docker 映像。

查看用于存储和拉取映像的 配额限制和使用情况。 释放已用存储器并更改服务套餐 或配额限制，以保持在给定配额限制内。

我尝试在单个管道作业中编译应用程序，为何失败?

您需要 4 GB 内存 (而不是文件存储器) 才能在单个管道作业中构建应用程序。

当我尝试在单个管道作业中编译应用程序时，构建作业失败，发生意外错误。

应用程序需要超过 4 GB 的内存才能在单个管道作业中进行编译。

要在单个管道作业中构建应用程序:

1. 创建一个 IBM Cloud® Continuous Delivery 管道私人工作者。
2. 配置构建作业以使用 专用工作程序。

为什么 Delivery Pipeline 无法通过防火墙进行通信?

防火墙配置会阻止 Delivery Pipeline 与防火墙后的环境进行通信。

当我尝试使用 Delivery Pipeline时，它无法通过我的防火墙进行通信。

您的防火墙必须配置为允许 Delivery Pipeline 与防火墙后的环境进行通信。

您可以更新防火墙配置，以允许 Delivery Pipeline 访问防火墙后的资源。 将 CIS 允许列表 和 子网范围 用于特定区域。

为什么我收到通知，指出存储库引用在我的管道触发器或定义中是固定的?

您已从工具链更改，添加或除去存储库集成，这导致对存储在管道触发器或定义中的集成的引用变为无效。

当我在工具链中更改，添加或除去存储库集成时，会在管道配置中显示警告图标和验证错误。

在某些场景中，当您从工具链更改，添加或除去存储库集成时，对存储在管道触发器或定义中的这些集成的引用可能会变为无效。

如果匹配的存储库集成位于工具链中，那么管道会尝试自动更新这些引用以修复无效的集成引用。 将在 UI 中显示通知，其中包含下列其中一条消息:

• Repository reference fixed in the following triggers: [list of triggers]
• Repository reference fixed in the following definitions: [list of definitions]

如果您看到其中一个通知，但配置中未显示任何警告或错误，那么无需进一步操作。 如果仍显示警告或错误，那么可能需要重新更新或创建触发器或定义。

为什么我的管道在尝试连接到 IBM Cloud Object Storage 私有端点时会超时？

运行管道时，向使用私有端点的 IBM Cloud Object Storage 提出的请求会超时，且无响应。 超时会导致管道失败。

IBM Cloud Object Storage 无法从所有 IBM Cloud 集群类型访问专用端点。 无法从在 IBM Cloud® Virtual Private Cloud (VPC) 中的集群上运行的专用工作程序访问专用 IBM Cloud Object Storage 端点。

将任何 s3.private.* IBM Cloud Object Storage 端点替换为 s3.direct.* 端点。s3.direct.* 端点是从任何 IBM Cloud 集群类型与 IBM Cloud Object Storage 通信的直接端点。

为什么我的管道由于与安全属性相关的错误而失败?

当管道中的任何安全属性在管道运行启动时无法解析时，PipelineRuns 将失败并返回错误。

无法从私钥存储库或从 Secrets Manager，Key Protect或 HashiCorp 保险库文件检索私钥值的管道失败，并显示指示无法解析哪些属性的错误消息。 即使在触发的运行中未直接使用属性，也会发生解析失败。 例如，如果商店中私钥的路径不再有效，私钥商店不可访问或存在授权问题，那么可能会发生解析失败。

如果管道包含当前未解析的安全属性，请更新这些属性以引用位于 Secrets Manager，Key Protect或 HashiCorp 保险库文件中的有效可检索私钥。

确保管道仅指定成功完成触发的 PipelineRun 作为管道触发器属性 (而不是管道级别环境属性) 所需的安全属性。 仅在需要时使用管道级别环境属性。

为什么我的管道报告访存管道定义时发生错误?

Delivery Pipeline 页面上出现与访存管道定义相关的错误。 或者，尝试触发 PipelineRun时出现错误。

访存管道的定义时，可能会发生故障的原因有很多。 例如，如果定义是在一个大型版本库中定义的，那么获取定义的请求可能会超时，原因是在构建定义之前克隆大型版本库时出现了延迟。 另一个示例是当定义输入以存储库中不再存在的分支或路径为目标时。

请尝试使用下列其中一个选项来解决问题:

• 重新装入页面以启动新请求来访存定义。 如果此操作重复失败，请继续使用以下选项。
• 验证定义输入中所有引用的分支和路径是否与存储库中存在的资源匹配。
• 减小包含 Tekton 定义的存储库的大小。 从存储库中除去不必要的文件，并更新 .gitignore 以排除上载任何不必要的文件。
• 仅包含管道定义的最小必需文件-请勿将整个存储库作为目标。 将所有与 Tekton 定义相关的文件移动到存储库的子文件夹中，然后编辑 Delivery Pipeline 设置中的定义输入，以子文件夹为目标路径。 此选项可减少从存储库克隆定义文件所需的时间。
• 对于较大的 Tekton 定义，可考虑将定义拆分为多个文件夹或多个存储库。 然后，更新 Delivery Pipeline 中的定义输入，将必要的文件夹或资源库作为目标。

计算的管道定义大小限制为 1 MB。 如果在保存或运行管道时迂到错误，那么可能需要减小管道定义的大小，或者将其拆分为多个管道。

为什么我的管道无法连接到 Red Hat OpenShift on IBM Cloud 集群?

尝试 oc login 的管道无法登录正在运行 Red Hat OpenShift on IBM Cloud V 4.13 及更高版本的目标集群。

该问题由 Red Hat OpenShift on IBM Cloud 4.13 版中引入的一项变更引起。

要解决此问题，请使用以下过程:

ibmcloud login --apikey "${IBMCLOUD_API_KEY}" -r "${REGION}" -g "${RESOURCE_GROUP}"
ibmcloud oc cluster config --cluster "${CLUSTER_NAME}" --endpoint private --admin
kubectl config current-context
oc version
oc get pods -A  # To verify connection

为什么我的管道在运行 Git 克隆命令时会失败？

使用 "git-clone-repo 命令任务的 Tekton 管道可能会失败，并显示以下错误：

Clone was not successful. Code 128 - Retrying shortly...
fatal: destination path '.' already exists and is not an empty directory.

这个问题是由公共管理管道工人基础设施的性能变化引起的。

要解决此问题，请完成下列步骤：

• 找到管道设置下的 tekton 定义，并找到路径下的 "git 条目。 点击资源库链接打开。 导航至“git/task-clone-repo.yaml，然后在该文件中找到”clone-repo 步骤。 请参考 Tekton 目录示例 中的最新代码。
• 在 git clone 调用之前的定义中添加 rm -rf "lost+found"。 这样可以确保克隆目录为空。
• 再次运行管道。

从试用账户运行时，为什么我的管道无法在托管工作者上启动？

从试用账户运行的经典管道无法启动，原因是出现以下错误：

This type of account is not entitled to use managed workers. Private workers can be used instead or to gain access managed worker capability the account must be upgraded to a paid plan.

此行为是由试用帐户许可权的修订引起的。

尝试以下选项来解决这个问题：

• 使用运行在自己集群上的私有 Worker 运行管道。
• 使用轻量套餐将试用帐户升级到 现收现付 帐户。

为什么我的管道无法触发来自分叉仓库的拉取请求事件？

管道默认不响应来自分叉源的拉取请求事件

设计这种行为是为了防止无意中执行管道。

要启用管道运行来自分叉源的事件，请执行以下操作：

• Tekton 管道：在 Git 触发器窗口中，启用 Include pull request events from forks 切换按钮
• 经典管道：在舞台配置的 "输入 "选项卡上，启用 "Include pull request events from forks 切换按钮