本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

故障排除 CodePipeline

以下信息可帮助您处理 AWS CodePipeline中的常见问题。

管道错误：管道配置为 AWS Elastic Beanstalk 返回错误消息：“部署失败。提供的角色没有足够的权限： Service:AmazonElasticLoadBalancing”

问题：的服务角色 CodePipeline 没有足够的权限执行 Elastic Load Balancing 中的某些操作，包括但不限于这些操作。 AWS Elastic Beanstalk的服务角色已于 CodePipeline 2015 年 8 月 6 日更新，以解决此问题。在此日期之前创建其服务角色的客户必须修改其服务角色的策略语句以添加所需的权限。

可能的修复措施：最简单的解决方案是编辑服务角色的策略声明，详情请参见为 CodePipeline 服务角色添加权限。

应用编辑过的策略后，按照手动启动管道中的步骤手动重新运行使用 Elastic Beanstalk 的任何管道。

根据您的安全需求，您也可以通过其他方式修改权限。

部署错误：管道配置了 AWS Elastic Beanstalk 如果缺少 “DescribeEvents” 权限，部署操作将挂起而不是失败

问题：的服务角色 CodePipeline 必须包括使用的所有管道的"elasticbeanstalk:DescribeEvents"操作 AWS Elastic Beanstalk。如果没有此权限， AWS Elastic Beanstalk 部署操作会挂起而不会失败或显示错误。如果您的服务角色中缺少此操作， CodePipeline 则无权 AWS Elastic Beanstalk 代表您运行管道部署阶段。

可能的修复：查看您的 CodePipeline 服务角色。如果缺少 "elasticbeanstalk:DescribeEvents" 操作，请使用为 CodePipeline 服务角色添加权限中的步骤在 IAM 控制台中使用编辑策略功能添加它。

应用编辑过的策略后，按照手动启动管道中的步骤手动重新运行使用 Elastic Beanstalk 的任何管道。

管道错误：源操作返回权限不足消息：“无法访问 CodeCommit 存储库存储库名称。确保管道 IAM 角色具有足够的权限来访问存储库。”

问题：的服务角色 CodePipeline 没有足够的权限，很可能是在 2016 年 4 月 18 日添加对使用 CodeCommit存储库的支持之前创建的。 CodeCommit 在此日期之前创建其服务角色的客户必须修改其服务角色的策略语句以添加所需的权限。

可能的修复：将所需的权限 CodeCommit 添加到您的 CodePipeline 服务角色的策略中。有关更多信息，请参阅 为 CodePipeline 服务角色添加权限。

管道错误：Jenkins 生成或测试操作运行很长时间后由于缺少凭证或权限而失败

问题：如果 Jenkins 服务器安装在 Amazon EC2 实例上，则该实例可能不是使用具有所需权限的实例角色创建的 CodePipeline。如果您在 Jenkins 服务器、本地实例或不是使用所需 IAM 角色创建的 Amazon EC2 实例上使用 IAM 用户，则 IAM 用户将不具有所需权限，或者 Jenkins 服务器将无法通过服务器上配置的配置文件访问这些凭证。

可能的修复措施：确保为 Amazon EC2 实例角色或 IAM 用户配置 AWSCodePipelineCustomActionAccess 托管策略或等效权限。有关更多信息，请参阅 AWS 的托管策略 AWS CodePipeline。

如果您使用的是 IAM 用户，请确保在实例上 AWS 配置的配置文件使用配置了正确权限的 IAM 用户。您可能需要提供为在 Jenkins 之间集成以及 CodePipeline 直接集成到 Jenkins 用户界面而配置的 IAM 用户证书。这不是推荐的最佳实践。如果必须这样做，请确保 Jenkins 服务器是安全的，并且使用 HTTPS 而不是 HTTP。

管道错误：在管道中创建了一个管道 AWS 使用在另一个存储桶中创建的存储桶的区域 AWS 区域返回一个 “InternalError”，代码为 “JobFailed”

问题：如果管道和存储桶是在不同的 AWS 区域创建的，则存储在 Amazon S3 存储桶中的对象的下载将失败。

可能的解决方法：确保存储对象的 Amazon S3 存储桶与您创建的管道位于同一 AWS 区域。

部署错误：包含 WAR 文件的 ZIP 文件已成功部署到 AWS Elastic Beanstalk，但是应用程序 URL 报告了 404 未找到错误

问题：WAR 文件已成功部署到 AWS Elastic Beanstalk 环境，但应用程序 URL 返回 404 Not Found 错误。

可能的修复： AWS Elastic Beanstalk 可以解压缩 ZIP 文件，但不能解压缩 ZIP 文件中包含的 WAR 文件。不要在 buildspec.yml 文件中指定 WAR 文件，而是指定一个包含要部署的内容的文件夹。例如：

version: 0.2

phases:
  post_build:
    commands:
      - mvn package
      - mv target/my-web-app ./
artifacts:
  files:
    - my-web-app/**/*
 discard-paths: yes

有关示例，请参阅适用于 CodeBuild 的AWS Elastic Beanstalk 示例。

管道构件文件夹名称似乎被截断

问题：当您在中查看管道对象名称时 CodePipeline，名称似乎被截断了。这可能会使名称看似或似乎不再包含整个管道名称。

解释： CodePipeline 截断项目名称以确保在为工作人员 CodePipeline 生成临时证书时，完整的 Amazon S3 路径不会超过策略大小限制。

尽管对象名称似乎已被截断，但 CodePipeline 映射到对象存储桶的方式不会受到名称被截断的构件的影响。管道可以正常工作。这不是文件夹或构件的问题。管道名称不能超过 100 个字符。尽管构件文件夹名称似乎已缩短，但它对您的管道来说仍然是唯一的。

添加 CodeBuild GitClone 连接到 Bitbucket GitHub、 GitHub 企业服务器或 GitLab.com

当您在源操作和操作 AWS CodeConnections 中使用时 CodeBuild ，可以通过两种方式将输入构件传递给构建：

要向 CodeBuild 服务角色策略添加权限，您需要创建客户管理的策略并将其附加到您的 CodeBuild 服务角色。以下步骤创建策略，在该策略中指定UseConnection权限，在action字段中指定连接 ARN，通过Condition限制源存储库 ID。Resource

为 CodeCommit 源操作添加 CodeBuild GitClone 权限

当您的管道有 CodeCommit 源操作时，可以通过两种方式将输入构件传递给构建：

要向 CodeBuild 服务角色策略添加权限，您需要创建客户管理的策略并将其附加到您的 CodeBuild 服务角色。以下步骤将创建一个在 action 字段中指定 codecommit:GitPull 权限的策略。

管道错误：带有 CodeDeployToECS 操作的部署会返回一条错误消息：“尝试从以下来源读取任务定义构件文件时出现异常：<源对象名称>”

问题：

任务定义文件是通过 CodeDeploy （操作）向 Amazon ECS 进行 CodePipeline 部署CodeDeployToECS操作的必备工具。CodeDeployToECS 部署操作中的构件 ZIP 大小上限为 3 MB。如果找不到文件或构件大小超过 3 MB，则会返回以下错误消息：

尝试从以下位置读取任务定义构件文件时出现异常：<source artifact name>

可能的修复措施：确保包含任务定义文件构件。如果文件已经存在，请确保压缩后的大小小于 3 MB。

GitHub （通过 OAuth 应用程序）源操作：存储库列表显示不同的存储库

问题：

在 CodePipeline 控制台中成功授权 GitHub （通过 OAuth 应用程序）操作后，您可以从仓库列表中进行选择。 GitHub 如果列表中不包括您期望看到的存储库，则可以对用于授权的账户进行故障排除。

可能的修复： CodePipeline 控制台中提供的仓库列表基于授权账户所属的 GitHub 组织。确认您用于授权的账户 GitHub 是与创建仓库 GitHub 的组织关联的账户。

GitHub （通过 GitHub 应用程序）源操作：无法完成存储库的连接

问题：

由于与 GitHub 仓库的连接使用 AWS 连接器 GitHub，因此您需要组织所有者权限或仓库管理员权限才能创建连接。

可能的修复：有关 GitHub 仓库权限级别的信息，请参阅 https://docs.github.com/en/free-pro-team @ latest/github /设置和管理组织和--levels-for-an-an-an-teams/permission organizations。

Amazon S3 错误： CodePipeline 服务角色 < ARN > 被拒绝 S3 存储桶的 S3 访问权限 < BucketName >

问题：

在进行过程中，中的 CodeCommit 操作 CodePipeline 会检查管道工件存储桶是否存在。如果操作没有权限检查，则 Amazon S3 中会出现AccessDenied错误，并在中显示以下错误消息 CodePipeline：

CodePipeline 服务角色 “arn: aws: iam::AccountID: role/service-role/RoleID” 被拒绝 S3 存储桶的 S3 访问权限” BucketName

该操作的 CloudTrail 日志也记录了AccessDenied错误。

可能的修复措施：执行以下操作：

应用编辑过的策略后，按照手动启动管道中的步骤手动重新运行管道。

带有 Amazon S3、Amazon ECR 或 CodeCommit 源的管道不再自动启动

问题：

更改使用事件规则（EventBridge或 CloudWatch 事件）进行变更检测的操作的配置设置后，如果源触发器标识符相似且初始字符相同，则控制台可能无法检测到更改。由于新的事件规则不是由控制台创建的，因此管道不再自动启动。

在参数名称末尾稍作更改的一个示例是 CodeCommit 将您的 CodeCommit 分支名称更改MyTestBranch-1为MyTestBranch-2。由于更改位于分支名称的末尾，因此源操作的事件规则可能不会为新的源设置更新或创建规则。

这适用于使用 CWE 事件进行更改检测的源操作，如下所示：

可能的修复方法：

请执行以下操作之一：

在控制台中编辑操作配置后，接受控制台创建的已更新的更改检测资源。

连接时出现连接错误 GitHub：“出现问题，请确保在浏览器中启用 Cookie” 或 “组织所有者必须安装 GitHub 应用程序”

问题：

要为中的 GitHub 源操作创建连接 CodePipeline，您必须是 GitHub组织所有者。对于不属于组织的存储库，您必须是存储库拥有者。当连接由非组织拥有者的其他用户创建时，将针对组织拥有者创建请求，并显示以下错误之一：

出现问题，请确保在浏览器中启用 Cookie

或

组织所有者必须安装该 GitHub 应用程序

可能的修复：对于 GitHub组织中的仓库，组织所有者必须创建与 GitHub 仓库的连接。对于不属于组织的存储库，您必须是存储库拥有者。

当达到运行限制时，将执行模式更改为 QUEUED 或 PARALLEL 模式的管道会失败

问题：在 QUEUED 模式下，管道的最大并发执行数为 50 个。当达到此限制时，管道会失败，但不显示状态消息。

可能的修复：为执行模式编辑管道定义时，请与其它编辑操作分开进行。

有关 QUEUED 或 PARALLEL 执行模式的更多信息，请参阅 CodePipeline 概念。

如果将 PARALLEL 模式下的管道编辑为 QUEUED 或 SUPERSEDED 模式，则管道定义会过时

问题：对于 PARALLEL 模式下的管道，将管道执行模式编辑为 QUEUED 或 SUPERSEDED 时，不会更新 PARALLEL 模式的管道定义。更新并行模式时更新的流水线定义不在 SUPERSEDED 或 QUEUED 模式中使用。

可能的修复：对于 PARALLEL 模式下的管道，在将管道执行模式编辑为 QUEUED 或 SUPERSEDED 时，应避免同时更新管道定义。

有关 QUEUED 或 PARALLEL 执行模式的更多信息，请参阅 CodePipeline 概念。

从 PARALLEL 模式更改的管道将显示之前的执行模式

问题：对于 PARALLEL 模式下的管道，将管道执行模式编辑为 QUEUED 或 SUPERSEDED 时，管道状态不会将更新的状态显示为 PARALLEL。如果管道从 PARALLEL 变成 QUEUED 或 SUPERSEDED，则管道在 SUPERSEDED 或 QUEUED 模式下的状态将是这两种模式下的最后已知状态。如果管道从未在该模式下运行过，则状态为空。

可能的修复：对于 PARALLEL 模式下的管道，将管道执行模式编辑为 QUEUED 或 SUPERSEDED 时，注意执行模式显示将不显示 PARALLEL 状态。

有关 QUEUED 或 PARALLEL 执行模式的更多信息，请参阅 CodePipeline 概念。

具有使用文件路径触发筛选的连接的管道可能不会在创建分支时启动

描述：对于具有使用连接的源操作（例如 BitBucket 源操作）的管道，您可以使用 Git 配置设置触发器，该触发器允许您按文件路径筛选以启动管道。在某些情况下，对于具有按文件路径筛选的触发器的管道，当首次创建带有文件路径筛选器的分支时，管道可能无法启动，因为这不允许 CodeConnections 连接解析更改的文件。当触发器的 Git 配置设置为筛选文件路径时，当刚刚在源存储库中创建带有过滤器的分支时，管道将不会启动。有关筛选文件路径的更多信息，请参阅添加带有代码推送或拉取请求事件类型的触发器。

结果：例如，创建分支 “B” 时不会触发在 CodePipeline 分支 “B” 上具有文件路径筛选器的管道。如果没有文件路径筛选条件，管道仍将启动。

当达到文件限制时，具有使用文件路径触发筛选的连接的管道可能无法启动

描述：对于具有使用连接的源操作（例如 BitBucket 源操作）的管道，您可以使用 Git 配置设置触发器，该触发器允许您按文件路径筛选以启动管道。 CodePipeline 最多检索前 100 个文件；因此，当触发器的 Git 配置设置为筛选文件路径时，如果文件超过 100 个，管道可能无法启动。有关筛选文件路径的更多信息，请参阅添加带有代码推送或拉取请求事件类型的触发器。

结果：例如，如果差异包含 150 个文件， CodePipeline则查看前 100 个文件（不分先后）以检查指定的文件路径过滤器。如果与文件路径过滤器匹配的文件不在检索的 100 个文件中 CodePipeline，则不会调用管道。

CodeCommit 或者并行模式下的 S3 源版本可能与 EventBridge 事件不匹配

描述：对于并行模式下的管道执行，执行可能会从最新的更改（例如 CodeCommit 存储库提交）开始，这可能与 EventBridge 事件的更改不同。在某些情况下，启动管道的提交或图像标签之间可能存在一瞬间，当 CodePipeline接收到事件并开始执行时，推送了另一个提交或图像标签， CodePipeline （例如， CodeCommit 动作）将在那一刻克隆 HEAD 提交。

结果：对于使用 CodeCommit或 S3 源的并行模式下的管道，无论触发管道执行的更改如何，源操作在启动时都将始终克隆 HEAD。例如，对于 PARALLEL 模式下的管道，推送一次提交，启动管道执行 1，管道执行 2 使用第二次提交。

EC2 部署操作失败并显示错误消息没有这样的文件

描述：在 EC2 部署操作解压缩实例目标目录中的构件后，该操作将运行脚本。如果脚本位于目标目录中，但该操作无法运行该脚本，则该实例的操作失败，其余实例的部署也将失败。

目标目录为 /home/ec2-user/deploy/、源存储库路径为 myRepo/postScript.sh 的部署的日志中会显示类似于以下错误消息的错误。

结果：管道中的部署操作失败。

可能的修复方法：使用以下步骤进行问题排查。

EKS 部署操作失败并显示群集无法访问错误消息

描述：EKS 部署操作运行后，操作失败并显示错误消息“cluster unreachable”。该消息显示由于缺少权限而导致集群中的访问问题。根据文件类型（Helm 图表或 Kubernetes 清单文件），错误消息显示如下。

结果：管道中的部署操作失败。

可能的修复：如果使用现有角色，则必须使用使用 EKS 部署操作所需的权限更新 CodePipeline 服务角色。此外，要允许 CodePipeline 服务角色访问您的集群，您必须向集群添加访问条目并为访问条目指定服务角色。

当多个源操作引用同一个存储库时，不会触发所有分支的管道

问题：管道有多个使用连接的源操作（例如 Bitbucket 或 GitLab 连接），每个源操作都指向同一存储库的不同分支。 GitHub当您推送更改时，只有一个分支会触发管道。连接的 webhook 订阅是针对管道和存储库组合注册的，而不是按分支注册的。因此，不支持针对单个管道中同一存储库的不同分支的多个源操作。

可能的修复方法：为要独立触发的每个分支使用单独的管道。

需要有关其他问题的帮助？

尝试其他资源：