Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异，请参阅 中国的 Amazon Web Services 服务入门 (PDF)。

CodePipeline 故障排除

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

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

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

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

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

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

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

问题：对于使用 Amazon Elastic Beanstalk 的任何管道，CodePipeline 的服务角色必须包含 "elasticbeanstalk:DescribeEvents" 操作。没有此权限，Amazon Elastic Beanstalk 部署操作会挂起但不会失败或指示错误。如果您的服务角色缺少此操作，则 CodePipeline 将无权代表您在 Amazon Elastic Beanstalk 中运行管道部署阶段。

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

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

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

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

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

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

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

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

如果您正在使用 IAM 用户，请确保实例上配置的 Amazon 配置文件使用配置了正确权限的 IAM 用户。您可能必须直接在 Jenkins UI 中提供您配置的用于在 Jenkins 和 CodePipeline 之间进行集成的 IAM 用户凭证。这不是推荐的最佳实践。如果必须这样做，请确保 Jenkins 服务器是安全的，并且使用 HTTPS 而不是 HTTP。

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

问题：如果管道和 Amazon S3 桶是在不同的 Amazon 区域中创建的，那么下载存储在该桶中的构件会失败。

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

部署错误：包含 WAR 文件的 ZIP 文件已成功部署到 Amazon Elastic Beanstalk，但应用程序 URL 报告 404 Not Found 错误

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

可能的修复措施：Amazon 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 的 Amazon Elastic Beanstalk 示例。

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

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

解释：CodePipeline 会截断构件名称，以确保在 CodePipeline 为任务工作者生成临时凭证时，完整的 Amazon S3 路径不超过策略大小限制。

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

添加 CodeBuild GitClone 权限以连接到 Bitbucket、GitHub、GitHub Enterprise Server 或 GitLab.com

当您在源操作和 CodeBuild 操作中使用 AWS CodeStar 连接时，可以通过两种方式将输入构件传递到生成包：

要向 CodeBuild 服务角色策略添加权限，请创建附加到 CodeBuild 服务角色的客户管理型策略。以下步骤会创建一个策略，其中 UseConnection 权限在 action 字段中指定，而连接 ARN 在 Resource 字段中指定。

为 CodeCommit 源操作添加 CodeBuild GitClone 权限

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

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

管道错误：使用 CodeDeployToECS 操作的部署返回错误消息：“Exception while trying to read the task definition artifact file from: <source artifact name> (尝试从 <源构件名称> 读取任务定义构件时发生异常)”

问题：

任务定义文件是 CodePipeline 通过 CodeDeploy 向 Amazon ECS 执行部署操作（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 存储库的连接使用 Amazon Connector for GitHub，因此您需要组织所有者权限或存储库的管理员权限才能创建连接。

可能的修复措施：有关 GitHub 存储库的权限级别的信息，请参阅 https://docs.github.com/en/free-pro-team@latest/github/setting-up-and-managing-organizations-and-teams/permission-levels-for-an-organization。

Amazon S3 错误：CodePipeline 服务角色 <ARN> 正在拒绝 S3 访问 S3 桶 <BucketName>

问题：

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

CodePipeline 服务角色“arn:aws:iam::AccountID:role/service-role/RoleID”正在拒绝 S3 访问 S3 桶“桶名称”

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

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

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

包含 Amazon S3、Amazon ECR 或 CodeCommit 源的管道不再自动启动

问题：

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

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

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

可能的修复方法：

请执行以下操作之一：

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

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

问题：

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

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

或

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

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

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

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

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

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

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

问题：对于 PARALLEL 模式下的管道，将管道执行模式编辑为 QUEUED 或 SUPERSEDED 时，不会更新 PARALLEL 模式的管道定义。更新 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 个文件（不按特定顺序），并根据指定的文件路径筛选条件进行检查。如果与文件路径筛选条件匹配的文件不在 CodePipeline 检索的 100 个文件中，管道将不会被调用。

PARALLEL 模式下的 CodeCommit 或 S3 源修订可能与 EventBridge 事件不匹配

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

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

EC2 部署操作失败并显示错误消息“No such file”

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

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

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

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

EKS 部署操作失败并显示错误消息“cluster unreachable”

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

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

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

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

尝试其他资源：