本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。 # 故障排除 CodePipeline 以下信息可帮助您处理 AWS CodePipeline中的常见问题。 **Topics** + [管道错误：配置为的管道 AWS Elastic Beanstalk 会返回一条错误消息：“部署失败。提供的角色没有足够的权限：服务：AmazonElasticLoadBalancing”](#troubleshooting-aeb1) + [部署错误：如果缺少 “DescribeEvents” 权限，则配置了 AWS Elastic Beanstalk 部署操作的管道会挂起而不是失败](#troubleshooting-aeb2) + [管道错误：源操作返回权限不足消息：“无法访问 CodeCommit 存储库`repository-name`。确保管道 IAM 角色具有足够的权限来访问存储库。”](#troubleshooting-service-role-permissions) + [管道错误：Jenkins 生成或测试操作运行很长时间后由于缺少凭证或权限而失败](#troubleshooting-jen1) + [管道错误：使用在另一个 AWS AWS 区域创建的存储桶在一个区域创建的管道会返回一个 InternalError “”，代码为 “JobFailed”](#troubleshooting-reg-1) + [部署错误：包含 WAR 文件的 ZIP 文件已成功部署到 AWS Elastic Beanstalk，但应用程序 URL 报告了 404 未找到错误](#troubleshooting-aeb2) + [管道构件文件夹名称似乎被截断](#troubleshooting-truncated-artifacts) + [添加连接 Bitbucket、 GitHub、En GitHub terprise Server 或 GitLab .com 的 CodeBuild GitClone 权限](#codebuild-role-connections) + [为 CodeCommit 源操作添加 CodeBuild GitClone 权限](#codebuild-role-codecommitclone) + [管道错误：使用 CodeDeployTo ECS 操作的部署会返回一条错误消息：“尝试从以下位置读取任务定义构件文件时出现异常：”](#troubleshooting-ecstocodedeploy-size) + [GitHub （通过 OAuth 应用程序）源操作：存储库列表显示不同的存储库](#troubleshooting-connections-GitHub-org) + [GitHub （通过 GitHub App）源操作：无法完成存储库的连接](#troubleshooting-connections-GitHub-admin) + [Amazon S3 错误： CodePipeline 服务角色对 S3 存储桶的 S3 访问被拒绝 < BucketName >](#troubleshooting-S3-access-denied-list) + [带有 Amazon S3、Amazon ECR 或 CodeCommit 源的管道不再自动启动](#troubleshooting-events-identifiers) + [连接时出现连接错误 GitHub：“出现问题，请确保您的浏览器已启用 Cookie” 或 “组织所有者必须安装 GitHub 应用程序”](#troubleshooting-connections-GitHub-organization-owner) + [执行模式更改为 QUEUED 或 PARALLEL 模式的管道在达到运行限制时失败](#troubleshooting-queued-mode) + [如果将 PARALLEL 模式下的管道编辑为 QUEUED 或 SUPERSEDED 模式，则管道定义会过时](#troubleshooting-execution-mode-editing) + [从 PARALLEL 模式更改的管道将显示之前的执行模式](#troubleshooting-execution-mode-displayedstate) + [具有使用文件路径触发筛选的连接的管道可能不会在创建分支时启动](#troubleshooting-file-paths-filtering) + [当达到文件限制时，具有使用文件路径触发筛选的连接的管道可能无法启动](#troubleshooting-file-paths-files) + [CodeCommit 或者并行模式下的 S3 源版本可能与 EventBridge 事件不匹配](#troubleshooting-revisions-parallel) + [EC2 部署操作失败并显示错误消息“`No such file`”](#troubleshooting-ec2-deploy) + [EKS 部署操作失败并显示错误消息“`cluster unreachable`”](#troubleshooting-eks-deploy) + [需要有关其他问题的帮助？](#troubleshooting-other) ## 管道错误：配置为的管道 AWS Elastic Beanstalk 会返回一条错误消息：“部署失败。提供的角色没有足够的权限：服务：AmazonElasticLoadBalancing” **问题：**的服务角色对于 Elastic Load Balancing 中的某些操作 CodePipeline 没有足够的权限 AWS Elastic Beanstalk，包括但不限于 Elastic Load Balancing 中的某些操作。的服务角色已 CodePipeline 于 2015 年 8 月 6 日更新，以解决此问题。在此日期之前创建其服务角色的客户必须修改其服务角色的策略语句以添加所需的权限。 **可能的修复措施：**最简单的解决方案是编辑服务角色的策略声明，详情请参见[为 CodePipeline 服务角色添加权限](how-to-custom-role.md#how-to-update-role-new-services)。 应用编辑过的策略后，按照[手动启动管道](pipelines-rerun-manually.md)中的步骤手动重新运行使用 Elastic Beanstalk 的任何管道。 根据您的安全需求，您也可以通过其他方式修改权限。 ## 部署错误：如果缺少 “DescribeEvents” 权限，则配置了 AWS Elastic Beanstalk 部署操作的管道会挂起而不是失败 **问题：**的服务角色 CodePipeline 必须包括使用的所有管道的`"elasticbeanstalk:DescribeEvents"`操作 AWS Elastic Beanstalk。如果没有此权限， AWS Elastic Beanstalk 部署操作将挂起而不会失败或显示错误。如果您的服务角色中缺少此操作， CodePipeline 则无权 AWS Elastic Beanstalk 代表您运行管道部署阶段。 **可能的修复方法：**查看您的 CodePipeline 服务角色。如果缺少 `"elasticbeanstalk:DescribeEvents"` 操作，请使用[为 CodePipeline 服务角色添加权限](how-to-custom-role.md#how-to-update-role-new-services)中的步骤在 IAM 控制台中使用**编辑策略**功能添加它。 应用编辑过的策略后，按照[手动启动管道](pipelines-rerun-manually.md)中的步骤手动重新运行使用 Elastic Beanstalk 的任何管道。 ## 管道错误：源操作返回权限不足消息：“无法访问 CodeCommit 存储库`repository-name`。确保管道 IAM 角色具有足够的权限来访问存储库。” **问题：**的服务角色 CodePipeline 没有足够的权限，很可能是在 2016 年 4 月 18 日添加对使用 CodeCommit存储库的支持之前创建的。 CodeCommit 在此日期之前创建其服务角色的客户必须修改其服务角色的策略语句以添加所需的权限。 **可能的修复方法：**将所需的权限 CodeCommit 添加到您的 CodePipeline 服务角色的策略中。有关更多信息，请参阅 [为 CodePipeline 服务角色添加权限](how-to-custom-role.md#how-to-update-role-new-services)。 ## 管道错误：Jenkins 生成或测试操作运行很长时间后由于缺少凭证或权限而失败 **问题：**如果 Jenkins 服务器安装在 Amazon EC2 实例上，则该实例可能不是使用具有所需权限的实例角色创建的 CodePipeline。如果您在 Jenkins 服务器、本地实例或不是使用所需 IAM 角色创建的 Amazon EC2 实例上使用 IAM 用户，则 IAM 用户将不具有所需权限，或者 Jenkins 服务器将无法通过服务器上配置的配置文件访问这些凭证。 **可能的修复措施：**确保为 Amazon EC2 实例角色或 IAM 用户配置 `AWSCodePipelineCustomActionAccess` 托管策略或等效权限。有关更多信息，请参阅 [AWS 的托管策略 AWS CodePipeline](managed-policies.md)。 如果您使用的是 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 示例](https://docs.aws.amazon.com/codebuild/latest/userguide/sample-elastic-beanstalk.html)。 ## 管道构件文件夹名称似乎被截断 **问题：**在中查看管道工件名称时 CodePipeline，名称似乎已被截断。这可能会使名称看似或似乎不再包含整个管道名称。 **解释：**在为作业人员 CodePipeline 生成临时证书时，会 CodePipeline 截断对象名称以确保完整的 Amazon S3 路径不会超过策略大小限制。 尽管工件名称似乎已被截断，但 CodePipeline 映射到工件存储桶的方式不会受到名称被截断的工件的影响。管道可以正常工作。这不是文件夹或构件的问题。管道名称不能超过 100 个字符。尽管构件文件夹名称似乎已缩短，但它对您的管道来说仍然是唯一的。 ## 添加连接 Bitbucket、 GitHub、En GitHub terprise Server 或 GitLab .com 的 CodeBuild GitClone 权限 在源代码 AWS CodeConnections 中使用操作和操作时，可以通过两种方式将输入构件传递给构建： CodeBuild + 默认：源操作生成一个 zip 文件，其中包含要 CodeBuild下载的代码。 + 完全克隆：源代码可以直接下载到构建环境中。 完全克隆模式允许您将源代码作为工作的 Git 存储库进行交互。要使用此模式，必须向您的 CodeBuild 环境授予使用连接的权限。 要向您的 CodeBuild 服务角色策略添加权限，您需要创建一个附加到您的 CodeBuild 服务角色的客户托管策略。以下步骤将创建一个策略，其中在字段中指定`UseConnection`权限，在`action`字段中指定连接 ARN，并通过限制源存储库 ID。`Resource` `Condition` **使用控制台添加 UseConnection 权限** 1. 要查找管道的连接 ARN 和源存储库 ID，请打开您的管道，单击源操作上的 (i) 图标，然后切换到 “**输入**” 选项卡。 连接 ARN 的示例是： ``` arn:aws:codeconnections:eu-central-1:123456789123:connection/sample-1908-4932-9ecc-2ddacee15095 ``` 源存储库 ID 的示例： ``` owner/test-app ``` 您将连接 ARN 和存储库 ID 添加到您的 CodeBuild 服务角色策略中。 1. 要查找您的 CodeBuild 服务角色，请选择管道中使用的构建项目，然后导航到**构建详细信息**选项卡。 1. 选择**服务角色**链接。此时将打开 IAM 控制台，您可以在其中添加新策略，以授予对连接的访问权限。 1. 在 IAM 控制台中，选择**添加权限**，然后选择**创建内联策略**。 使用以下示例策略模板。在字段中添加您的连接 ARN，在`Resource`字段中`codeconnections:FullRepositoryId`添加您的仓库 ID，如以下示例所示：`Condition` ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "codeconnections:UseConnection", "Resource": "arn:aws:codeconnections:eu-central-1:123456789123:connection/my-connection-id", "Condition": { "StringEquals": { "codeconnections:FullRepositoryId": "my-repository-id" } } } ] } ``` ------ 使用该`Condition`字段根据您的构建规范要求进一步缩小策略权限的范围（参见`CodeConnection`条件[文档](https://docs.aws.amazon.com/dtconsole/latest/userguide/security-iam.html#permissions-reference-connections-use)）。 在存储库的 **JSON** 选项卡上，粘贴您的策略。 1. 选择**下一步**。为策略输入名称（例如 **connection-permissions**），然后选择 **Create policy (创建策略)**。 您将看到**connection-permissions**附加到您的角色的**策略权限策略**。 ## 为 CodeCommit 源操作添加 CodeBuild GitClone 权限 当你的管道有 CodeCommit 源代码操作时，有两种方法可以将输入构件传递给构建： + **默认**-源操作生成一个 zip 文件，其中包含要 CodeBuild 下载的代码。 + **完整克隆** – 源代码可以直接下载到构建环境中。 **完整克隆**选项允许您将源代码作为工作 Git 存储库进行交互。要使用此模式，必须为 CodeBuild环境添加从存储库中提取数据的权限。 要向您的 CodeBuild 服务角色策略添加权限，您需要创建一个附加到您的 CodeBuild 服务角色的客户托管策略。以下步骤将创建一个在 `action` 字段中指定 `codecommit:GitPull` 权限的策略。 **使用控制台添加 GitPull 权限** 1. 要查找您的 CodeBuild 服务角色，请打开管道中使用的构建项目，然后导航到**构建详细信息**选项卡。 1. 选择**服务角色**链接。此时将打开 IAM 控制台，您可以在其中添加新策略，以授予对存储库的访问权限。 1. 在 IAM 控制台中，选择 **Attach policies (附加策略)**，然后选择 **Create policy (创建策略)**。 1. 在 **JSON** 选项卡上，粘贴以下示例策略。 ``` { "Action": [ "codecommit:GitPull" ], "Resource": "*", "Effect": "Allow" }, ``` 1. 选择**查看策略**。为策略输入名称（例如 **codecommit-gitpull**），然后选择 **Create policy (创建策略)**。 1. 返回到附加权限的页面上，刷新策略列表，然后选择您刚才创建的策略。选择**附加策略**。 ## 管道错误：使用 CodeDeployTo ECS 操作的部署会返回一条错误消息：“尝试从以下位置读取任务定义构件文件时出现异常：” **问题：** 任务定义文件是通过 CodeDeploy （操作） CodePipeline 部署到 Amazon ECS 的`CodeDeployToECS`操作所必需的对象。`CodeDeployToECS` 部署操作中的构件 ZIP 大小上限为 3 MB。如果找不到文件或构件大小超过 3 MB，则会返回以下错误消息： 尝试从以下位置读取任务定义构件文件时出现异常： **可能的修复措施：**确保包含任务定义文件构件。如果文件已经存在，请确保压缩后的大小小于 3 MB。 ## GitHub （通过 OAuth 应用程序）源操作：存储库列表显示不同的存储库 **问题：** 在 CodePipeline 控制台中成功授权 GitHub （通过 OAuth 应用程序）操作后，您可以从 GitHub 存储库列表中进行选择。如果列表中不包括您期望看到的存储库，则可以对用于授权的账户进行故障排除。 **可能的修复方法：** CodePipeline 控制台中提供的存储库列表基于授权账户所属的 GitHub 组织。验证您用于授权的账户是否 GitHub 是与创建仓库的 GitHub 组织关联的账户。 ## GitHub （通过 GitHub App）源操作：无法完成存储库的连接 **问题：** 由于与 GitHub 存储库的连接使用 AWS 连接器 GitHub，因此您需要组织所有者权限或仓库管理员权限才能创建连接。 **可能的修复方法：**有关 GitHub 存储库权限级别的信息，请参阅 [https://docs.github.com/en/free-pro-team@ latest/github/setting-up-and-managing-organizations-and-teams/permission-levels-for-an-organization](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 服务角色对 S3 存储桶的 S3 访问被拒绝 < BucketName > **问题：** 在进行过程中，中的 CodeCommit 操作 CodePipeline 会检查管道工件存储桶是否存在。如果操作无权检查，则 Amazon S3 中会出现`AccessDenied`错误，并在中显示以下错误消息 CodePipeline： CodePipeline 服务角色 “arn: aws: iam::: role/service-role/*AccountID*” 无法访问 S3 存储桶 “” *RoleID* *BucketName* 该操作的 CloudTrail 日志也会记录`AccessDenied`错误。 **可能的修复措施：**执行以下操作： + 对于附加到您的 CodePipeline 服务角色的策略，`s3:ListBucket`请添加到策略中的操作列表中。有关查看您的服务角色策略的说明，请参阅[查看管道 ARN 和服务角色 ARN（控制台）](pipelines-settings-console.md)。编辑您的服务角色的策略声明，详情请参见[为 CodePipeline 服务角色添加权限](how-to-custom-role.md#how-to-update-role-new-services)。 + 对于附加到管道的 Amazon S3 项目存储桶的基于资源的策略（也称为*项目存储桶策略*），请添加一条语句以允许您的 CodePipeline 服务角色使用该`s3:ListBucket`权限。 **将您的策略添加到构件桶** 1. 按照[查看管道 ARN 和服务角色 ARN（控制台）](pipelines-settings-console.md)中的步骤在管道**设置**页面上选择您的构件桶，然后在 Amazon S3 控制台中进行查看。 1. 选择**权限**。 1. 在 **Bucket policy (存储桶策略)** 下，请选择 **Edit (编辑)**。 1. 在**策略**文本字段中，输入新的桶策略，或编辑现有策略，如以下示例所示。桶策略是一个 JSON 文件，因此您必须输入有效的 JSON。 以下示例显示了项目存储桶的存储桶策略声明，其中服务角色的示例角色 ID 为*AROAEXAMPLEID*。 ``` { "Effect": "Allow", "Principal": "*", "Action": "s3:ListBucket", "Resource": "arn:aws:s3:::BucketName", "Condition": { "StringLike": { "aws:userid": "AROAEXAMPLEID:*" } } } ``` 以下示例显示了添加权限后的相同桶策略声明。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Id": "SSEAndSSLPolicy", "Statement": [ { "Effect": "Allow", "Principal": "*", "Action": "s3:ListBucket", "Resource": "arn:aws:s3:::amzn-s3-demo-bucket", "Condition": { "StringLike": { "aws:userid": "AROAEXAMPLEID:*" } } }, { "Sid": "DenyUnEncryptedObjectUploads", "Effect": "Deny", "Principal": "*", "Action": "s3:PutObject", "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*", "Condition": { "StringNotEquals": { "s3:x-amz-server-side-encryption": "aws:kms" } } }, { "Sid": "DenyInsecureConnections", "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*", "Condition": { "Bool": { "aws:SecureTransport": false } } } ] } ``` ------ 有关更多信息，请参阅[https://aws.amazon.com/blogs/security/writing-iam-policies-how-to-grant-access-to-an-amazon-s3-bucket/](https://aws.amazon.com/blogs/security/writing-iam-policies-how-to-grant-access-to-an-amazon-s3-bucket/) 中的步骤。 1. 选择**保存**。 应用编辑过的策略后，按照[手动启动管道](pipelines-rerun-manually.md)中的步骤手动重新运行管道。 ## 带有 Amazon S3、Amazon ECR 或 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 或 CloudFormation 来创建和更新您的变更检测事件规则。有关为 S3 源操作创建事件规则的说明，请参阅[连接到使用 EventBridge 和的 Amazon S3 源操作 AWS CloudTrail](create-cloudtrail-S3-source.md)。有关为 Amazon ECR 操作创建事件规则的说明，请参阅[Amazon ECR 源操作和 EventBridge 资源](create-cwe-ecr-source.md)。有关为操作创建事件规则的 CodeCommit 说明，请参阅[CodeCommit 源操作和 EventBridge](triggering.md)。 在控制台中编辑操作配置后，接受控制台创建的已更新的更改检测资源。 ## 连接时出现连接错误 GitHub：“出现问题，请确保您的浏览器已启用 Cookie” 或 “组织所有者必须安装 GitHub 应用程序” **问题：** 要在中为 GitHub 源操作创建连接 CodePipeline，您必须是 GitHub组织所有者。对于不属于组织的存储库，您必须是存储库拥有者。当连接由非组织拥有者的其他用户创建时，将针对组织拥有者创建请求，并显示以下错误之一： 出现问题，请确保在浏览器中启用 Cookie 或 组织所有者必须安装该 GitHub 应用程序 **可能的修复方法：**对于 GitHub组织中的仓库，组织所有者必须创建与 GitHub 存储库的连接。对于不属于组织的存储库，您必须是存储库拥有者。 ## 执行模式更改为 QUEUED 或 PARALLEL 模式的管道在达到运行限制时失败 **问题：**在 QUEUED 模式下，管道的最大并发执行数为 50 个。当达到此限制时，管道会失败，但不显示状态消息。 **可能的修复：**为执行模式编辑管道定义时，请与其它编辑操作分开进行。 有关 QUEUED 或 PARALLEL 执行模式的更多信息，请参阅 [CodePipeline 概念 ](concepts.md)。 ## 如果将 PARALLEL 模式下的管道编辑为 QUEUED 或 SUPERSEDED 模式，则管道定义会过时 **问题：**对于 PARALLEL 模式下的管道，将管道执行模式编辑为 QUEUED 或 SUPERSEDED 时，不会更新 PARALLEL 模式的管道定义。更新 PARALLEL 模式时更新的管道定义不会在 SUPERSEDED 或 QUEUED 模式中使用 **可能的修复：**对于 PARALLEL 模式下的管道，在将管道执行模式编辑为 QUEUED 或 SUPERSEDED 时，应避免同时更新管道定义。 有关 QUEUED 或 PARALLEL 执行模式的更多信息，请参阅 [CodePipeline 概念 ](concepts.md)。 ## 从 PARALLEL 模式更改的管道将显示之前的执行模式 **问题：**对于 PARALLEL 模式下的管道，将管道执行模式编辑为 QUEUED 或 SUPERSEDED 时，管道状态不会将更新的状态显示为 PARALLEL。如果管道从 PARALLEL 变成 QUEUED 或 SUPERSEDED，则管道在 SUPERSEDED 或 QUEUED 模式下的状态将是这两种模式下的最后已知状态。如果管道从未在该模式下运行过，则状态为空。 **可能的修复：**对于 PARALLEL 模式下的管道，将管道执行模式编辑为 QUEUED 或 SUPERSEDED 时，注意执行模式显示将不显示 PARALLEL 状态。 有关 QUEUED 或 PARALLEL 执行模式的更多信息，请参阅 [CodePipeline 概念 ](concepts.md)。 ## 具有使用文件路径触发筛选的连接的管道可能不会在创建分支时启动 **描述：**对于具有使用连接的源操作的管道（例如 BitBucket 源操作），您可以使用 Git 配置设置触发器，允许您按文件路径筛选以启动管道。在某些情况下，对于具有按文件路径筛选的触发器的管道，当首次创建带有文件路径筛选器的分支时，管道可能无法启动，因为这不允许 CodeConnections 连接解析已更改的文件。当触发器的 Git 配置设置为根据文件路径筛选时，源存储库中刚刚创建了带有筛选条件的分支，管道就不会启动。有关根据文件路径筛选的更多信息，请参阅[添加带有代码推送或拉取请求事件类型的触发器](pipelines-filter.md)。 **结果：**例如 CodePipeline ，在分支 “B” 上具有文件路径筛选器的管道在创建分支 “B” 时不会被触发。如果没有文件路径筛选条件，管道仍将启动。 ## 当达到文件限制时，具有使用文件路径触发筛选的连接的管道可能无法启动 **描述：**对于具有使用连接的源操作的管道（例如 BitBucket 源操作），您可以使用 Git 配置设置触发器，允许您按文件路径筛选以启动管道。 CodePipeline 最多检索前 100 个文件；因此，当触发器的 Git 配置设置为筛选文件路径时，如果文件超过 100 个，管道可能无法启动。有关筛选文件路径的更多信息，请参阅[添加带有代码推送或拉取请求事件类型的触发器](pipelines-filter.md)。 **结果：**例如，如果差异包含 150 个文件，则 CodePipeline查看前 100 个文件（排名不分先后），根据指定的文件路径筛选器进行检查。如果与文件路径筛选器匹配的文件不在检索的 100 个文件中 CodePipeline，则不会调用管道。 ## CodeCommit 或者并行模式下的 S3 源版本可能与 EventBridge 事件不匹配 **描述：**对于并行模式下的管道执行，执行可能从最近的更改（例如 CodeCommit 存储库提交）开始，该更改可能与 EventBridge 事件的更改不同。在某些情况下，在启动管道的提交或图像标签之间可能有一瞬间，当 CodePipeline收到事件并开始执行时，另一个提交或图像标签已被推送 CodePipeline （例如， CodeCommit 操作）将在那时克隆 HEAD 提交。 **结果：**对于处于并行模式且源为 CodeCommit S3 的管道，无论触发管道执行的更改如何，源操作都将始终在启动时克隆 HEAD。例如，对于 PARALLEL 模式下的管道，推送一次提交，启动管道执行 1，管道执行 2 使用第二次提交。 ## EC2 部署操作失败并显示错误消息“`No such file`” **描述：**在 EC2 部署操作解压缩实例目标目录中的构件后，该操作将运行脚本。如果脚本位于目标目录中，但该操作无法运行该脚本，则该实例的操作失败，其余实例的部署也将失败。 目标目录为 `/home/ec2-user/deploy/`、源存储库路径为 `myRepo/postScript.sh` 的部署的日志中会显示类似于以下错误消息的错误。 + ``` Instance i-0145a2d3f3EXAMPLE is FAILED on event AFTER_DEPLOY, message: ----------ERROR------- chmod: cannot access '/home/ec2-user/deploy/myRepo/postScript.sh': No such file or directory /var/lib//_script.sh: line 2: /home/ec2-user/deploy/myRepo/postScript.sh: No such file or directory failed to run commands: exit status 127 ``` + ``` Executing commands on instances i-0145a2d3f3EXAMPLE, SSM command id , commands: chmod u+x /home/ec2-user/deploy/script.sh ----------ERROR-------: No such file or directory ``` **结果：**管道中的部署操作失败。 **可能的修复方法：**使用以下步骤进行问题排查。 1. 查看日志以确认导致脚本失败的实例。 1. 将目录（`cd`）更改为实例上的目标目录。在实例上测试运行脚本。 1. 在源存储库中，编辑脚本文件以删除可能导致问题的任何注释或命令。 ## EKS 部署操作失败并显示错误消息“`cluster unreachable`” **描述：**EKS 部署操作运行后，操作失败并显示错误消息“`cluster unreachable`”。该消息显示由于缺少权限而导致集群中的访问问题。根据文件类型（Helm 图表或 Kubernetes 清单文件），错误消息显示如下。 + 对于使用 Helm 图表的 EKS 部署操作，将显示类似于以下错误消息的错误。 ``` error message: helm upgrade --install my-release test-chart --wait Error: Kubernetes cluster unreachable: the server has asked for the client to provide credentials ``` + 对于使用 Kubernetes 清单文件的 EKS 部署操作，将显示类似于以下错误消息的错误。 ``` kubectl apply -f deployment.yaml Error: error validating "deployment.yaml": error validating data: failed to download openapi: the server has asked for the client to provide credentials ``` **结果：**管道中的部署操作失败。 **可能的修复方法：**如果使用现有角色，则必须将 CodePipeline 服务角色更新为使用 EKS 部署操作所需的权限。此外，要允许 CodePipeline 服务角色访问您的集群，您必须向集群添加访问条目并为访问条目指定服务角色。 1. 验证 CodePipeline 服务角色是否具有 EKS 部署操作所需的权限。有关权限参考，请参阅[服务角色策略权限](action-reference-EKS.md#action-reference-EKS-service-role)。 1. 向集群添加访问条目并指定访问权限的 CodePipeline 服务角色。有关示例，请参阅[步骤 4：为 CodePipeline 服务角色创建访问条目](tutorials-eks-deploy.md#tutorials-eks-deploy-access-entry)。 ## 需要有关其他问题的帮助？ 尝试其他资源： + 请联系 [AWS Support](https://aws.amazon.com/contact-us/)。 + 在 [CodePipeline 论坛](https://forums.aws.amazon.com/forum.jspa?forumID=197)中提问。 + [请求提高限额](https://console.aws.amazon.com/support/home#/case/create%3FissueType=service-limit-increase)。有关更多信息，请参阅 [AWS CodePipeline 中的限额](limits.md)。 **注意** 最长可能需要两周的时间来处理提高限额的请求。