故障排除 CodePipeline - AWS CodePipeline
管道错误：使用 AWS Elastic Beanstalk 配置的管道返回错误消息：“部署失败。提供的角色没有足够的权限：服务：AmazonElasticLoadBalancing”部署错误：如果缺少 “DescribeEvents” 权限，则配置了 AWS Elastic Beanstalk 部署操作的管道会挂起而不是失败管道错误：源操作返回权限不足消息：“无法访问 CodeCommit 存储库repository-name。确保管道IAM角色有足够的权限访问存储库。”管道错误：Jenkins 生成或测试操作运行很长时间后由于缺少凭证或权限而失败管道错误：使用在另一个 AWSAWS 区域创建的存储桶在一个区域创建的管道会返回一个 InternalError “”，代码为 “JobFailed”部署错误：包含ZIP文件的WAR文件已成功部署到 AWS Elastic Beanstalk，但应用程序URL报告了 404 未找到错误管道构件文件夹名称似乎被截断添加连接 Bitbucket、 GitHub、En GitHub terprise Server 或 GitLab .com 的 CodeBuild GitClone 权限为 CodeCommit源操作添加 CodeBuild GitClone 权限管道错误：带有 CodeDeployToECS操作的部署会返回一条错误消息：“尝试从以下位置读取任务定义构件文件时出现异常：<source artifact name>”GitHub 版本 1 源操作：存储库列表显示不同的存储库GitHub 版本 2 源操作：无法完成存储库的连接Amazon S3 错误： CodePipeline 服务角色 < ARN > 拒绝访问 S3 存储桶 < BucketName >带有 Amazon S3 ECR、Amazon 或 CodeCommit来源的管道不再自动启动连接时出现连接错误 GitHub：“出现问题，请确保您的浏览器已启用 Cookie” 或 “组织所有者必须安装 GitHub 应用程序”当达到运行限制时，执行模式更改为QUEUED或PARALLEL模式的管道会失败如果在更改为QUEUED或PARALLEL模式时进行编辑，则处于SUPERSEDED模式的管道定义会过时从PARALLEL模式更改的管道将显示之前的执行模式使用按文件路径进行触发器筛选的连接的管道可能无法在创建分支时启动当达到文件限制时，使用按文件路径进行触发器筛选的连接的管道可能无法启动CodeCommit 或者PARALLEL模式下的 S3 源版本可能与 EventBridge 事件不匹配 需要有关其他问题的帮助？

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

故障排除 CodePipeline

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

主题

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

可能的修复方法：确保存储您的项目的 Amazon S3 存储桶与您创建的管道位于同一 AWS 区域。

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

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

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

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 个字符。尽管构件文件夹名称似乎已缩短，但它对您的管道来说仍然是唯一的。

添加连接 Bitbucket、 GitHub、En GitHub terprise Server 或 GitLab .com 的 CodeBuild GitClone 权限

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

  • 默认：源操作生成一个 zip 文件，其中包含要 CodeBuild下载的代码。

  • Git 克隆：源代码可以直接下载到构建环境中。

    Git 克隆模式允许您将源代码作为工作 Git 存储库进行交互。要使用此模式，必须向您的 CodeBuild 环境授予使用连接的权限。

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

使用控制台添加 UseConnection 权限

  1. 要查找管道ARN的连接，请打开管道并单击源操作上的 (i) 图标。您将连接ARN添加到您的 CodeBuild 服务角色策略中。

    一个示例连接ARN是：

    arn:aws:codeconnections:eu-central-1:123456789123:connection/sample-1908-4932-9ecc-2ddacee15095

  2. 要查找您的 CodeBuild 服务角色，请打开管道中使用的构建项目，然后导航到构建详细信息选项卡。

  3. 选择服务角色链接。这将打开IAM控制台，您可以在其中添加授予连接访问权限的新策略。

  4. 在IAM控制台中，选择附加策略，然后选择创建策略。

    使用以下示例策略模板。在Resource字段ARN中添加您的连接，如以下示例所示：

    {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "codestar-connections:UseConnection",
            "Resource": "insert connection ARN here"
        }
    ]
}

    在JSON选项卡上，粘贴您的政策。

  5. 选择查看策略。为策略输入名称（例如 connection-permissions），然后选择 Create policy (创建策略)。

  6. 返回到附加权限的页面上，刷新策略列表，然后选择您刚才创建的策略。选择附加策略。

    该图显示了在控制台中附加策略的选项

为 CodeCommit源操作添加 CodeBuild GitClone 权限

当你的管道有 CodeCommit 源代码操作时，有两种方法可以将输入构件传递给构建：

  • 默认-源操作生成一个 zip 文件，其中包含要 CodeBuild 下载的代码。

  • 完整克隆 – 源代码可以直接下载到构建环境中。

    完整克隆选项允许您将源代码作为工作 Git 存储库进行交互。要使用此模式，必须为 CodeBuild环境添加从存储库中提取数据的权限。

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

使用控制台添加 GitPull 权限

  1. 要查找您的 CodeBuild 服务角色，请打开管道中使用的构建项目，然后导航到构建详细信息选项卡。

  2. 选择服务角色链接。这将打开IAM控制台，您可以在其中添加授予对存储库访问权限的新策略。

  3. 在IAM控制台中，选择附加策略，然后选择创建策略。

  4. 在JSON选项卡上，粘贴以下示例策略。

    {
    "Action": [
        "codecommit:GitPull"
    ],
    "Resource": "*",
    "Effect": "Allow"
},

  5. 选择查看策略。为策略输入名称（例如 codecommit-gitpull），然后选择 Create policy (创建策略)。

  6. 返回到附加权限的页面上，刷新策略列表，然后选择您刚才创建的策略。选择附加策略。

管道错误：带有 CodeDeployToECS操作的部署会返回一条错误消息：“尝试从以下位置读取任务定义构件文件时出现异常：<source artifact name>”

问题：

任务定义文件是ECS通过向 Amazon CodePipeline 部署操作 CodeDeploy （CodeDeployToECS操作）的必需项目。CodeDeployToECS部署操作中的最大对象ZIP大小为 3 MB。如果找不到文件或构件大小超过 3 MB，则会返回以下错误消息：

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

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

GitHub 版本 1 源操作：存储库列表显示不同的存储库

问题：

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

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

GitHub 版本 2 源操作：无法完成存储库的连接

问题：

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

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

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

问题：

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

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

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

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

  • 对于附加到您的 CodePipeline 服务角色的策略，s3:ListBucket请添加到策略中的操作列表中。有关查看您的服务角色策略的说明，请参阅查看管道ARN和服务角色ARN（控制台）。编辑您的服务角色的策略声明，详情请参见向 CodePipeline 服务角色添加权限。

  • 对于附加到管道的 Amazon S3 项目存储桶的基于资源的策略（也称为项目存储桶策略），请添加一条语句以允许您的 CodePipeline 服务角色使用该s3:ListBucket权限。

    将您的策略添加到构件桶

    1. 按照查看管道ARN和服务角色ARN（控制台）中的步骤在管道设置页面上选择您的构件桶，然后在 Amazon S3 控制台中进行查看。

    2. 选择权限。

    3. 在 Bucket policy (存储桶策略) 下，请选择 Edit (编辑)。

    4. 在策略文本字段中，输入新的桶策略，或编辑现有策略，如以下示例所示。存储桶策略是一个JSON文件，因此您必须输入有效的策略JSON。

      以下示例显示了项目存储桶的存储桶策略声明，其中服务角色的示例角色 ID 为 AROAEXAMPLEID.

      {
    "Effect": "Allow",
    "Principal": "*",
    "Action": "s3:ListBucket",
    "Resource": "arn:aws:s3:::BucketName",
    "Condition": {
        "StringLike": {
            "aws:userid": "AROAEXAMPLEID:*"
        }
    }
}

      以下示例显示了添加权限后的相同桶策略声明。

      {
    "Version": "2012-10-17",
    "Id": "SSEAndSSLPolicy",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:ListBucket",
            "Resource": "arn:aws:s3:::codepipeline-us-east-2-1234567890",
            "Condition": {
                "StringLike": {
                    "aws:userid": "AROAEXAMPLEID:*"
                }
            }
        },
        {
            "Sid": "DenyUnEncryptedObjectUploads",
            "Effect": "Deny",
            "Principal": "*",
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::codepipeline-us-east-2-1234567890/*",
            "Condition": {
                "StringNotEquals": {
                    "s3:x-amz-server-side-encryption": "aws:kms"
                }
            }
        },
        {
            "Sid": "DenyInsecureConnections",
            "Effect": "Deny",
            "Principal": "*",
            "Action": "s3:*",
            "Resource": "arn:aws:s3:::codepipeline-us-east-2-1234567890/*",
            "Condition": {
                "Bool": {
                    "aws:SecureTransport": false
                }
            }
        }
    ]
}

      有关更多信息，请参阅https://aws.amazon.com/blogs/security/writing-iam-policies-how-to-grant-access-to-an-amazon-s3-bucket/ 中的步骤。

    5. 选择保存。

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

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

问题：

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

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

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

源操作 参数/触发器标识符（控制台）
Amazon ECR

存储库名称

映像标签
Amazon S3

存储桶

S3 对象键
CodeCommit

存储库名称

分支名称

可能的修复措施：

请执行以下操作之一：

  • 更改 CodeCommit /S3/ ECR 配置设置，以便更改参数值的起始部分。

    示例：将分支名称 release-branch 更改为 2nd-release-branch。避免在名称末尾进行更改，例如 release-branch-2。

  • 更改每个管 CodeCommit道的 /S3/ ECR 配置设置。

    示例：将分支名称 myRepo/myBranch 更改为 myDeployRepo/myDeployBranch。避免在名称末尾进行更改，例如 myRepo/myBranch2。

  • 使用CLI或代替控制台 AWS CloudFormation 来创建和更新您的变更检测事件规则。有关为 S3 源操作创建事件规则的说明，请参阅连接到使用 EventBridge 和的 Amazon S3 源操作 AWS CloudTrail。有关为 Amazon ECR 操作创建事件规则的说明，请参阅 Amazon ECR 来源操作和 EventBridge 资源。有关为操作创建事件规则的 CodeCommit 说明，请参阅 CodeCommit 源操作和 EventBridge。

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

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

问题：

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

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

或

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

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

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

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

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

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

如果在更改为QUEUED或PARALLEL模式时进行编辑，则处于SUPERSEDED模式的管道定义会过时

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

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

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

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

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

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

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

使用按文件路径进行触发器筛选的连接的管道可能无法在创建分支时启动

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

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

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

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

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

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

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

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

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

尝试其他资源：