翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # CodePipeline のトラブルシューティング 以下の情報は、 AWS CodePipelineでの一般的な問題のトラブルシューティングに役立ちます。 **Topics** + [パイプラインエラー: で設定されたパイプラインは、「デプロイに失敗しました」というエラーメッセージ AWS Elastic Beanstalk を返します。提供されたロールに十分なアクセス権限がありません: サービス: AmazonElasticLoadBalancing」](#troubleshooting-aeb1) + [デプロイエラー: AWS Elastic Beanstalk デプロイアクションで設定されたパイプラインは、DescribeEvents」アクセス許可がない場合に失敗するのではなくハングします](#troubleshooting-aeb2) + [パイプラインのエラー: ソースアクションは次のようなアクセス許可の不足メッセージを返します。「CodeCommit リポジトリ `repository-name` にアクセスできませんでした。」 リポジトリにアクセスするための十分な権限がパイプラインの IAM ロールにあることを確認してください。」](#troubleshooting-service-role-permissions) + [パイプラインのエラー: Jenkins のビルドまたはテストアクションが長期間実行された後、認証情報やアクセス許可の不足のため失敗します。](#troubleshooting-jen1) + [パイプラインエラー: 別の AWS リージョンで作成されたバケットを使用してある AWS リージョンで作成されたパイプラインは、JobFailed」というコードのInternalError」を返します。](#troubleshooting-reg-1) + [デプロイエラー: WAR ファイルを含む ZIP ファイルは正常にデプロイされますが AWS Elastic Beanstalk、アプリケーション URL は 404 が見つかりませんというエラーを報告します](#troubleshooting-aeb2) + [パイプラインのアーティファクトフォルダ名が切り詰められているように見えます](#troubleshooting-truncated-artifacts) + [Bitbucket、GitHub、GitHub Enterprise Server、または GitLab.com に接続するための CodeBuild GitClone アクセス許可を追加します。](#codebuild-role-connections) + [CodeBuild GitClone のアクセス権限を CodeCommit ソースアクションに追加します。](#codebuild-role-codecommitclone) + [パイプラインのエラー: CodeDeployToECS アクションがあるデプロイから、「 からタスク定義アーティファクトファイルを読み取ろうとしたときに例外が発生しました」というエラーメッセージが返されます。](#troubleshooting-ecstocodedeploy-size) + [GitHub (OAuth アプリ経由) ソースアクション: リポジトリリストに異なるリポジトリが表示されます。](#troubleshooting-connections-GitHub-org) + [GitHub (GitHub アプリ経由) ソースアクション: リポジトリの接続を完了できません。](#troubleshooting-connections-GitHub-admin) + [Amazon S3 エラー: CodePipeline サービスロール により、S3 バケット に対する S3 アクセスが拒否されました。](#troubleshooting-S3-access-denied-list) + [Amazon S3 、Amazon ECR、または CodeCommit ソースを使用した パイプラインは自動的に起動されなくなりました。](#troubleshooting-events-identifiers) + [GitHub への接続時の Connections エラー:「問題が発生しました。ブラウザで 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) + [PARALLEL モードの 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」 **問題:** 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 を使用するパイプラインを手動で再実行します。 セキュリティのニーズに応じて、他の方法でアクセス権限を変更することもできます。 ## デプロイエラー: AWS Elastic Beanstalk デプロイアクションで設定されたパイプラインは、DescribeEvents」アクセス許可がない場合に失敗するのではなくハングします **問題:** 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 のサービスロールには CodeCommit に対する十分な権限がなく、CodeCommit リポジトリを使用するためのサポートが、2016 年 4 月 18 日に追加される前に作成された可能性があります。この日付より前にサービスロールを作成したお客様は、サービスロールのポリシーステートメントを変更して必要なアクセス権限を追加する必要があります。 **修正案:** CodeCommit に必要な権限を CodePipeline サービスロールのポリシーに追加します。詳細については、「[CodePipeline サービスロールにアクセス許可を追加する](how-to-custom-role.md#how-to-update-role-new-services)」を参照してください。 ## パイプラインのエラー: Jenkins のビルドまたはテストアクションが長期間実行された後、認証情報やアクセス許可の不足のため失敗します。 **問題:** Jenkins サーバーが Amazon EC2 インスタンスにインストールされている場合、インスタンスは CodePipeline に必要な権限を持つインスタンスロールで作成されていない可能性があります。Jakins サーバー、オンプレミスインスタンス、または必要な IAM ロールなしで作成された Amazon EC2 インスタンスで IAM ユーザーを使用している場合、IAM ユーザーには必要な権限がないか、Jenkins サーバーがサーバー上に設定されたプロファイルを介してこれらの認証情報にアクセスできません。 **修正案:** Amazon EC2 インスタンスロールまたは IAM ユーザーが、`AWSCodePipelineCustomActionAccess` 管理されたポリシーまたは同等の権限で設定されていることを確認します。詳細については、「[AWS の 管理ポリシー AWS CodePipeline](managed-policies.md)」を参照してください。 IAM ユーザーを使用している場合は、インスタンスで設定された AWS プロファイルが正しいアクセス許可で設定された IAM ユーザーを使用していることを確認してください。Jenkins と CodePipeline の統合のために設定した IAM ユーザー認証情報を Jenkins UI に直接提供する必要があります。これは推奨されるベストプラクティスではありません。その必要がある場合は、Jenkins サーバーが保護されており、HTTP ではなく HTTPS を使用していることを確認してください。 ## パイプラインエラー: 別の AWS リージョンで作成されたバケットを使用してある AWS リージョンで作成されたパイプラインは、JobFailed」というコードのInternalError」を返します。 **問題:** パイプラインとバケットが異なる 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 ``` 例については、「[AWS Elastic Beanstalk CodeBuild のサンプル ](https://docs.aws.amazon.com/codebuild/latest/userguide/sample-elastic-beanstalk.html)」を参照してください。 ## パイプラインのアーティファクトフォルダ名が切り詰められているように見えます **問題:** パイプラインのアーティファクト名を CodePipeline で表示すると、名前が切り詰められているように見えます。これにより、複数の名前が同じように表示されたり、パイプライン名全体の表示が失われたりしたように見えます。 **説明:** CodePipeline はアーティファクト名を切り詰めることにより、CodePipeline でジョブワーカーの一時的な認証情報を生成するときに、Amazon S3 のフルパスがポリシーサイズの上限を超えないようにします。 アーティファクト名が切り詰められたように見えても、CodePipeline は、名前が切り詰められたアーティファクトに影響されない方法でアーティファクトバケットにマッピングします。パイプラインは正常に動作します。これは、フォルダやアーティファクトでは問題となりません。パイプライン名には 100 文字の制限があります。アーティファクトフォルダ名は、短縮されたように見えても、パイプラインに対して依然として一意です。 ## Bitbucket、GitHub、GitHub Enterprise Server、または GitLab.com に接続するための CodeBuild GitClone アクセス許可を追加します。 ソースアクションと CodeBuild アクション AWS CodeConnections で を使用する場合、入力アーティファクトをビルドに渡す方法は 2 つあります。 + デフォルト: ソースアクションは、CodeBuild がダウンロードするコードを含む zip ファイルを生成します。 + フルクローン: ソースコードはビルド環境に直接ダウンロードできます。 フルクローンモードでは、作業中の Git リポジトリとしてソースコードを操作できます。このモードを使用するには、接続を使用するためのアクセス許可を CodeBuild 環境 に付与する必要があります。 CodeBuild サービスロールポリシーにアクセス許可を追加するには、CodeBuild サービスロールにアタッチするカスタマーマネージドポリシーを作成します。次の手順では、 `action`フィールドで`UseConnection`アクセス許可を指定し、 `Resource`フィールドで接続 ARN を指定し、ソースリポジトリ ID を 経由で制限するポリシーを作成します`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`フィールドに追加し、リポジトリ ID を `Condition`フィールド`codeconnections:FullRepositoryId`の に追加します。 ------ #### [ 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**) を入力し、[**ポリシーの作成**] を選択します。 ロールのアクセス許可**connection-permissions**ポリシーにアタッチされたポリシーが表示されます。 **** ## CodeBuild GitClone のアクセス権限を CodeCommit ソースアクションに追加します。 パイプラインに CodeCommit ソースアクションがある場合、入力アーティファクトをビルドに渡す方法は 2 つあります。 + **デフォルト:** ソースアクションは、CodeBuild がダウンロードするコードを含む zip ファイルを生成します。 + **フルクローン:** ソースコードは、直接ビルド環境にダウンロードできます。 **フルクローン** オプションでは、作業中の Git リポジトリとしてソースコードを操作することができます。このモードを使用するには、CodeBuild 環境がリポジトリからプルするアクセス権限を追加する必要があります。 CodeBuild サービスロールポリシーにアクセス許可を追加するには、CodeBuild サービスロールにアタッチするカスタマーマネージドポリシーを作成します。次の手順では、`codecommit:GitPull` アクセス権限を `action` フィールドで指定するポリシーを作成します。 **コンソールを使用して GitPull のアクセス権限を追加するには** 1. CodeBuild サービスロールを確認するには、パイプラインで使用されているビルドプロジェクトを開き、[**Build details**] (ビルドの詳細) タブに移動します。 1. [**サービスロール**] リンクを選択します。これにより IAM コンソールが開き、リポジトリへのアクセスを許可する新しいポリシーを追加できます。 1. IAM コンソールで [**ポリシーのアタッチ**] を選択し、[**ポリシーの作成**] を選択します。 1. [**JSON**] タブに、以下のサンプルポリシーを貼り付けます。 ``` { "Action": [ "codecommit:GitPull" ], "Resource": "*", "Effect": "Allow" }, ``` 1. **[ポリシーの確認]** を選択します。ポリシーの名前 (例: **codecommit-gitpull**) を入力し、[**ポリシーの作成**] を選択します。 1. アクセス許可をアタッチしたページに戻り、ポリシーリストを更新して、作成したポリシーを選択します。**ポリシーのアタッチ** を選択します。 ## パイプラインのエラー: CodeDeployToECS アクションがあるデプロイから、「 からタスク定義アーティファクトファイルを読み取ろうとしたときに例外が発生しました」というエラーメッセージが返されます。 **問題:** タスク定義ファイルは、CodePipeline から Amazon ECS へのデプロイアクション (`CodeDeployToECS` アクション) に必要なアーティファクトです。`CodeDeployToECS` デプロイアクションのアーティファクト ZIP の最大サイズは 3 MB です。ファイルが見つからないかアーティファクトのサイズが 3 MB を超える場合は、次のエラーメッセージが返されます。 からタスク定義アーティファクトファイルを読み取ろうとしたときに例外が発生しました **解決方法:** タスク定義ファイルがアーティファクトとして含まれていることを確認してください。そのファイルが既に存在する場合は、圧縮サイズが 3 MB 未満であることを確認してください。 ## GitHub (OAuth アプリ経由) ソースアクション: リポジトリリストに異なるリポジトリが表示されます。 **問題:** CodePipeline コンソールで GitHub (OAuth アプリ経由) アクションの認可が成功したら、GitHub リポジトリのリストから選択できます。リストに表示されるはずのリポジトリが含まれていない場合は、認可に使用したアカウントをトラブルシューティングできます。 **解決方法:** CodePipeline コンソールで提供されるリポジトリのリストは、承認されたアカウントが属する GitHub Organization に基づいています。GitHub で認可するために使用しているアカウントが、リポジトリが作成されている GitHub Organization に関連付けられているアカウントであることを確認します。 ## GitHub (GitHub アプリ経由) ソースアクション: リポジトリの接続を完了できません。 **問題:** GitHub リポジトリへの接続は AWS 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](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 アクセスが拒否されました。 **問題:** 進行中、CodePipeline の CodeCommit アクションは、パイプラインアーティファクトバケットが存在することをチェックします。アクションにチェックするアクセス許可がない場合は、Amazon S3 で `AccessDenied` のエラーが発生し、CodePipeline に次のエラーメッセージが表示されます。 CodePipeline サービスロール「arn:aws:iam:: *AccountID* :role/service-role/*RoleID* により、S3 バケット「*BucketName*」の S3 アクセスが拒否されています。 アクションの 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. [**Permissions (アクセス許可)**] を選択します。 1. **[バケットポリシー]** で **[編集]** を選択します。 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 Events) を使用するアクションの設定を変更した後、ソーストリガーの識別子が類似していて、同じ初期文字を持っている場合、コンソールで変更を検出できないことがあります。新しいイベントルールはコンソールによって作成されないため、パイプラインは自動的に起動されなくなります。 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 への接続時の Connections エラー:「問題が発生しました。ブラウザで Cookie が有効になっていることを確認してください」または「組織の所有者は GitHub アプリケーションをインストールする必要があります」 **問題:** CodePipeline で GitHub ソースアクション用に接続を作成するには、GitHub 組織の所有者であることが必要です。組織のリポジトリではない場合、ユーザーがリポジトリの所有者である必要があります。接続の作成者が組織の所有者以外である場合、組織の所有者へのリクエストが作成され、次のエラーのいずれかが表示されます。 問題が発生しました。ブラウザで Cookie が有効になっていることを確認してください OR 組織の所有者は GitHub アプリケーションをインストールする必要があります **解決策:** GitHub 組織のリポジトリである場合、組織の所有者が GitHub リポジトリへの接続を作成する必要があります。組織のリポジトリでない場合、ユーザーがリポジトリの所有者である必要があります。 ## 実行モードを QUEUED または PARALLEL モードに変更したパイプラインは、実行制限に達すると失敗します **問題:** QUEUED モードのパイプラインの場合、同時実行の最大数は 50 です。この制限に達すると、パイプラインはステータスメッセージなしで失敗します。 **可能な修正:** 実行モードのパイプライン定義を編集するときは、他の編集アクションとは別に編集を行います。 QUEUED 実行モードまたは PARALLEL 実行モードの詳細については、「[CodePipeline の概念 ](concepts.md)」を参照してください。 ## PARALLEL モードのパイプラインは、QUEUED モードまたは SUPERSEDED モードに変更して編集したときに、パイプライン定義が古いままになります。 **問題:** 並列モードのパイプラインで、パイプライン実行モードを QUEUED または SUPERSEDED に編集したときに、PARALLEL モードのパイプライン定義は更新されません。PARALLEL モードの更新時に更新されたパイプライン定義は、SUPERSEDEDED モードまたは QUEUED モードでは使用されません。 **考えられる修正:** 並列モードのパイプラインの場合、パイプライン実行モードを QUEUED または SUPERSEDED に編集するときに、パイプライン定義を同時に更新しないでください。 QUEUED 実行モードまたは PARALLEL 実行モードの詳細については、「[CodePipeline の概念 ](concepts.md)」を参照してください。 ## PARALLEL モードから変更したパイプラインに、以前の実行モードが表示されます。 **問題:** PARALLEL モードのパイプラインで、パイプライン実行モードを QUEUED または SUPERSEDED に編集したときに、パイプライン状態には更新された状態が PARALLEL として表示されません。パイプラインを PARALLEL から QUEUED または SUPERSEDED に変更した場合、SUPERSEDED モードまたは QUEUED モードのパイプラインの状態は、そのいずれかのモードで最後に実行されたときの状態になります。パイプラインがそのモードで実行されたことがない場合、状態は空になります。 **考えられる修正：** 並列モードのパイプラインの場合、パイプライン実行モードを 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 個のファイル (特定の順序なし) を取得し、指定したファイルパスフィルターと照合します。ファイルパスフィルターと一致するファイルが CodePipeline が取得した 100 個のファイルに含まれていない場合、パイプラインは呼び出されません。 ## PARALLEL モードの CodeCommit または S3 ソースリビジョンは、EventBridge イベントと一致しない可能性があります **説明:** PARALLEL モードのパイプライン実行の場合、実行は CodeCommit リポジトリコミットなどの最新の変更で開始する場合があり、これは EventBridge イベントの変更とは異なることがあります。パイプラインを開始するコミット間やイメージタグ間に一瞬の差がある場合、CodePipeline がイベントを受信して実行を開始するときに、別のコミットやイメージタグがプッシュされると、CodePipeline (CodeCommit アクションなど) はその時点で HEAD コミットをクローンします。 **結果:** PARALLEL モードのパイプラインに CodeCommit または S3 ソースがある場合、パイプライン実行をトリガーした変更に関係なく、ソースアクションは常に開始時に HEAD をクローンします。例えば、PARALLEL モードのパイプラインの場合、コミットをプッシュすると、実行 1 のパイプラインが開始し、2 番目のパイプライン実行で 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)」を参照してください。 **注記** クォータの引き上げリクエストの処理には、最大 2 週間かかる場合があります。