トラブルシューティング CodePipeline - AWS CodePipeline
パイプラインのエラー: AWS Elastic Beanstalk で設定されたパイプラインは次のようなエラーメッセージを返します。「デプロイに失敗しました。提供されたロールに十分なアクセス許可がありません: サービス:AmazonElasticLoadBalancing」デプロイエラー:「」アクセスDescribeEvents許可がない場合に失敗するのではなく、AWS Elastic Beanstalkデプロイアクションで設定されたパイプラインがハングするパイプラインエラー: ソースアクションは、 CodeCommit 「リポジトリにアクセスできませんでした」という不十分なアクセス許可メッセージを返しますrepository-name。リポジトリにアクセスするための十分な権限がパイプラインの IAM ロールにあることを確認してください。」パイプラインのエラー: Jenkins のビルドまたはテストアクションが長期間実行された後、認証情報やアクセス許可の不足のため失敗します。パイプラインエラー: 別のAWSリージョンで作成されたバケットを使用してあるAWSリージョンで作成されたパイプラインは、コードInternalError「」を含む「」を返しますJobFailed。デプロイのエラー: WAR ファイルを含む ZIP ファイルは AWS Elastic Beanstalk に正常にデプロイされますが、アプリケーションの URL に 404 not found エラーがレポートされますパイプラインのアーティファクトフォルダ名が切り詰められているように見えますBitbucket、 GitHub Enterprise Server GitHub、または GitLab.com への接続の CodeBuild GitClone アクセス許可を追加するソースアクションの CodeBuild GitClone CodeCommitアクセス許可を追加するパイプラインエラー: CodeDeployToECS アクションを含むデプロイは、「タスク定義アーティファクトファイルを <ソースアーティファクト名> から読み込もうとしたときに例外が発生しました」というエラーメッセージを返します。GitHub バージョン 1 のソースアクション: リポジトリリストに異なるリポジトリが表示されるGitHub バージョン 2 のソースアクション: リポジトリへの接続を完了できないAmazon S3 エラー: CodePipeline サービスロール <ARN> が S3 バケット <BucketName> の S3 アクセスを拒否されていますAmazon S3、Amazon ECR、または CodeCommitソースを含むパイプラインが自動的に開始されなくなりましたへの接続時に接続エラーが発生する GitHub:「問題が発生しました。ブラウザで Cookie が有効になっていることを確認してください」または「組織の所有者が GitHub アプリをインストールする必要があります」CloudFormationStackSet または CloudFormationStackInstances アクションが特定のリージョンで使用できない場合のエラー実行制限に達すると、実行モードが QUEUED モードまたは PARALLEL モードに変更されたパイプラインが失敗するPARALLEL モードのパイプラインは、QUEUED モードまたは SUPERSED モードに変更したときに編集すると、パイプライン定義が古くなります。PARALLEL モードから変更されたパイプラインには、以前の実行モードが表示されます。ファイルパスによるトリガーフィルタリングを使用する接続を持つパイプラインは、ブランチの作成時に開始されない場合があります。ファイルパスによるトリガーフィルタリングを使用する接続を持つパイプラインは、ファイル制限に達したときに開始されない場合があります。別の問題があるため問い合わせ先を教えてください。

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

トラブルシューティング CodePipeline

以下の情報は、AWS CodePipeline での一般的な問題のトラブルシューティングに役立ちます。

トピック

パイプラインのエラー: AWS Elastic Beanstalk で設定されたパイプラインは次のようなエラーメッセージを返します。「デプロイに失敗しました。提供されたロールに十分なアクセス許可がありません: サービス:AmazonElasticLoadBalancing」

問題: のサービスロールにAWS Elastic Beanstalk、Elastic Load Balancing の一部のオペレーションを含む、 に対する十分なアクセス許可 CodePipeline がありません。のサービスロールは、この問題に対処するために 2015 年 8 月 6 日に更新 CodePipeline されました。この日付より前にサービスロールを作成したお客様は、サービスロールのポリシーステートメントを変更して必要なアクセス権限を追加する必要があります。

解決方法: 最も簡単な解決方法は、「 CodePipeline サービスロールにアクセス許可を追加する」で記載されているようにサービスロールに対するポリシーステートメントを編集することです。

編集済みのポリシーを適用したら、パイプラインを手動で開始する のステップに従って Elastic Beanstalk を使用するパイプラインを手動で再実行します。

セキュリティのニーズに応じて、他の方法でアクセス権限を変更することもできます。

デプロイエラー:「」アクセスDescribeEvents許可がない場合に失敗するのではなく、AWS Elastic Beanstalkデプロイアクションで設定されたパイプラインがハングする

問題: のサービスロールには、 を使用するパイプラインの "elasticbeanstalk:DescribeEvents"アクションが含まれている CodePipeline 必要があります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 可能性があります。この日付より前にサービスロールを作成したお客様は、サービスロールのポリシーステートメントを変更して必要なアクセス権限を追加する必要があります。

解決方法: CodePipeline サービスロールのポリシー CodeCommit に に必要なアクセス許可を追加します。詳細については、「 CodePipeline サービスロールにアクセス許可を追加する」を参照してください。

パイプラインのエラー: Jenkins のビルドまたはテストアクションが長期間実行された後、認証情報やアクセス許可の不足のため失敗します。

問題: Jenkins サーバーが Amazon EC2 インスタンスにインストールされている場合、 に必要なアクセス許可を持つインスタンスロールを使用してインスタンスが作成されていない可能性があります CodePipeline。Jakins サーバー、オンプレミスインスタンス、または必要な IAM ロールなしで作成された Amazon EC2 インスタンスで IAM ユーザーを使用している場合、IAM ユーザーには必要な権限がないか、Jenkins サーバーがサーバー上に設定されたプロファイルを介してこれらの認証情報にアクセスできません。

修正案: Amazon EC2 インスタンスロールまたは IAM ユーザーが、AWSCodePipelineCustomActionAccess 管理されたポリシーまたは同等の権限で設定されていることを確認します。詳細については、「AWS の マネージドポリシー AWS CodePipeline」を参照してください。

IAM ユーザーを使用している場合は、インスタンスで設定された AWS プロファイルが正しい権限で設定された IAM ユーザーを使用していることを確認してください。Jenkins と を Jenkins UI CodePipeline に直接統合するために設定した IAM ユーザー認証情報を提供する必要がある場合があります。これは推奨されるベストプラクティスではありません。その必要がある場合は、Jenkins サーバーが保護されており、HTTP ではなく HTTPS を使用していることを確認してください。

パイプラインエラー: 別のAWSリージョンで作成されたバケットを使用してあるAWSリージョンで作成されたパイプラインは、コードInternalError「」を含む「」を返しますJobFailed。

問題: パイプラインとバケットが異なる AWS リージョンに作成されていると、Amazon S3 バケットに保存されたアーティファクトのダウンロードは失敗します。

解決方法: アーティファクトが保存されている Amazon S3 バケットが、作成したパイプラインと同じ AWS リージョンにあることを確認します。

デプロイのエラー: WAR ファイルを含む ZIP ファイルは AWS Elastic Beanstalk に正常にデプロイされますが、アプリケーションの URL に 404 not found エラーがレポートされます

問題: 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」を参照してください。

パイプラインのアーティファクトフォルダ名が切り詰められているように見えます

問題: でパイプラインアーティファクト名を表示すると CodePipeline、名前が切り捨てられているように見えます。これにより、複数の名前が同じように表示されたり、パイプライン名全体の表示が失われたりしたように見えます。

explain: CodePipeline がジョブワーカーの一時的な認証情報 CodePipeline を生成するときに、完全な Amazon S3 パスがポリシーサイズの制限を超えないようにアーティファクト名を切り捨てます。

アーティファクト名が切り詰められたように見えても、 は、名前が切り詰められたアーティファクトの影響を受けない方法でアーティファクトバケットに CodePipeline マッピングします。パイプラインは正常に動作します。これは、フォルダやアーティファクトでは問題となりません。パイプライン名には 100 文字の制限があります。アーティファクトフォルダ名は、短縮されたように見えても、パイプラインに対して依然として一意です。

Bitbucket、 GitHub Enterprise Server GitHub、または GitLab.com への接続の CodeBuild GitClone アクセス許可を追加する

ソースアクションと CodeBuild アクションで AWS CodeStar接続を使用する場合、入力アーティファクトをビルドに渡す方法は 2 つあります。

  • デフォルト: ソースアクションは、 CodeBuild がダウンロードするコードを含む zip ファイルを生成します。

  • Git クローン: ソースコードは、直接ビルド環境にダウンロードできます。

    Git クローンモードでは、作業中の Git リポジトリとしてソースコードを操作することができます。このモードを使用するには、接続を使用するアクセス許可を CodeBuild 環境に付与する必要があります。

CodeBuild サービスロールポリシーにアクセス許可を追加するには、 CodeBuild サービスロールにアタッチするカスタマー管理ポリシーを作成します。次の手順では、UseConnection のアクセス許可が action フィールドに指定され、接続 ARN が Resource フィールドに指定されたポリシーを作成します。

コンソールを使用して UseConnection アクセス許可を追加するには
  1. パイプラインの接続 ARN を確認するには、パイプラインを開き、ソースアクションの (i) のアイコンをクリックします。接続 ARN を CodeBuild サービスロールポリシーに追加します。

    接続 ARN の例は以下のとおりです。

    arn:aws:codestar-connections: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) を入力し、[ポリシーの作成] を選択します。

  6. アクセス許可をアタッチしたページに戻り、ポリシーリストを更新して、作成したポリシーを選択します。[ポリシーのアタッチ] を選択します。

ソースアクションの CodeBuild GitClone CodeCommitアクセス許可を追加する

パイプラインに CodeCommit ソースアクションがある場合、入力アーティファクトをビルドに渡す方法は 2 つあります。

  • デフォルト – ソースアクションは、 が CodeBuild ダウンロードするコードを含む zip ファイルを生成します。

  • フルクローン: ソースコードは、直接ビルド環境にダウンロードできます。

    フルクローン オプションでは、作業中の Git リポジトリとしてソースコードを操作することができます。このモードを使用するには、環境が CodeBuildリポジトリからプルするアクセス許可を追加する必要があります。

CodeBuild サービスロールポリシーにアクセス許可を追加するには、 CodeBuild サービスロールにアタッチするカスタマー管理ポリシーを作成します。次の手順では、codecommit:GitPull アクセス権限を action フィールドで指定するポリシーを作成します。

コンソールを使用して GitPull アクセス許可を追加するには
  1. CodeBuild サービスロールを見つけるには、パイプラインで使用されているビルドプロジェクトを開き、「ビルドの詳細」タブに移動します。

  2. [サービスロール] リンクを選択します。これにより IAM コンソールが開き、リポジトリへのアクセスを許可する新しいポリシーを追加できます。

  3. IAM コンソールで [ポリシーのアタッチ] を選択し、[ポリシーの作成] を選択します。

  4. [JSON] タブに、以下のサンプルポリシーを貼り付けます。

    { "Action": [ "codecommit:GitPull" ], "Resource": "*", "Effect": "Allow" },
  5. [ポリシーの確認] を選択します。ポリシーの名前 (例: codecommit-gitpull) を入力し、[ポリシーの作成] を選択します。

  6. アクセス許可をアタッチしたページに戻り、ポリシーリストを更新して、作成したポリシーを選択します。[ポリシーのアタッチ] を選択します。

パイプラインエラー: CodeDeployToECS アクションを含むデプロイは、「タスク定義アーティファクトファイルを <ソースアーティファクト名> から読み込もうとしたときに例外が発生しました」というエラーメッセージを返します。

問題:

タスク定義ファイルは、 CodeDeploy ( アクション) を介して Amazon ECS に CodePipeline デプロイ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 Connector for を使用するため GitHub、接続を作成するには、リポジトリに対する組織所有者のアクセス許可または管理者のアクセス許可が必要です。

解決方法: GitHub リポジトリのアクセス許可レベルの詳細については、「https://docs.github.com/en/free-pro-team@latest/github/setting-up-and-managing-organizations-and-teams/permission-levels-for-anorganization」を参照してください。

Amazon S3 エラー: CodePipeline サービスロール <ARN> が S3 バケット <BucketName> の S3 アクセスを拒否されています

問題:

進行中、 の CodeCommit アクションはパイプラインアーティファクトバケットが存在する CodePipeline ことを確認します。アクションにチェックするアクセス許可がない場合、Amazon S3 でAccessDeniedエラーが発生し、 に次のエラーメッセージが表示されます CodePipeline。

CodePipeline サービスロール「arn:aws:iam::AccountID :role/service-role/RoleID」が S3 バケット「」の S3 アクセスを拒否していますBucketName

アクションの CloudTrail ログもAccessDeniedエラーをログに記録します。

解決方法: 次の作業を行います。

  • CodePipeline サービスロールにアタッチされたポリシーについては、ポリシー内のアクションのリストs3:ListBucketに を追加します。サービスロールポリシーを表示する手順については、「パイプラインの ARN とサービスロール ARN (コンソール) を表示します。」を参照してください。サービスロールのポリシーステートメントを編集するには「 CodePipeline サービスロールにアクセス許可を追加する」を参照してください。

  • パイプラインの Amazon S3 アーティファクトバケットにアタッチされたリソースベースのポリシーで、アーティファクトバケットポリシー とも呼ばれる場合は、 ステートメントを追加して、 CodePipeline サービスロールが アクセスs3:ListBucket許可を使用できるようにします。

    アーティファクトバケットにポリシーを追加するには
    1. パイプラインの ARN とサービスロール ARN (コンソール) を表示します。 の手順を行い、パイプラインの [設定] ページでアーティファクトバケットを選択し、Amazon S3 コンソールに表示させます。

    2. [Permissions (アクセス許可)] を選択します。

    3. [バケットポリシー][編集] を選択します。

    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、Amazon ECR、または CodeCommitソースを含むパイプラインが自動的に開始されなくなりました

問題:

変更検出にイベントルール (EventBridge または CloudWatch イベント) を使用するアクションの設定を変更した後、ソーストリガー識別子が類似していて、初期文字が同じである変更がコンソールで検出されない場合があります。新しいイベントルールはコンソールによって作成されないため、パイプラインは自動的に起動されなくなります。

のパラメータ名の末尾にわずかな変更を加える例として、 CodeCommit ブランチ名を MyTestBranch-1に変更 CodeCommit することが挙げられます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 リポジトリへの接続を作成する必要があります。組織のリポジトリでない場合、ユーザーがリポジトリの所有者である必要があります。

CloudFormationStackSet または CloudFormationStackInstances アクションが特定のリージョンで使用できない場合のエラー

問題: リージョン CodePipeline に が存在するからといって、そのリージョンですべてのアクションが使用できるとは限りません。例えば、アクションが利用できないリージョン (アフリカ (ケープタウン) など) でパイプラインが CloudFormationStackSet アクションを実行すると、以下のエラーが表示されます。

InvalidActionDeclarationException: ActionType (Category: 'Deploy', Provider: 'CloudFormationStackSet', Owner: 'AWS, Version: '1') in action 'Deploy' is not available in region 'AF_SOUTH_1'

考えられる解決方法: アクションが利用できるリージョンでそのアクションを使用するには、以下の注意事項を参照してください。

注記

CloudFormationStackSet および CloudFormationStackInstances アクションは、アジアパシフィック (香港)、欧州 (チューリッヒ)、欧州 (ミラノ)、アフリカ (ケープタウン) および中東 (バーレーン) リージョンでは利用できません。利用可能なその他のアクションについては、「との製品とサービスの統合 CodePipeline」を参照してください。

アクションの詳細については、「AWS CloudFormation StackSets」を参照してください。

実行制限に達すると、実行モードが QUEUED モードまたは PARALLEL モードに変更されたパイプラインが失敗する

問題: QUEUED モードでのパイプラインの同時実行の最大数は 50 回です。この制限に達すると、パイプラインは失敗し、ステータスメッセージが表示されます。

解決方法: 実行モードのパイプライン定義を編集するときは、他の編集アクションとは別に編集を行います。

QUEUED または PARALLEL 実行モードの詳細については、「」を参照してくださいCodePipeline の概念

PARALLEL モードのパイプラインは、QUEUED モードまたは SUPERSED モードに変更したときに編集すると、パイプライン定義が古くなります。

問題: 並列モードのパイプラインの場合、パイプライン実行モードを QUEUED または SUPERSEDED に編集すると、PARALLEL モードのパイプライン定義は更新されません。PARALLEL モードの更新時に更新されたパイプライン定義は、SUPERSEDED モードまたは QUEUED モードでは使用されません。

解決方法: 並列モードのパイプラインの場合、パイプライン実行モードを QUEUED または SUPERSED に編集するときは、パイプライン定義を同時に更新しないでください。

QUEUED または PARALLEL 実行モードの詳細については、「」を参照してくださいCodePipeline の概念

PARALLEL モードから変更されたパイプラインには、以前の実行モードが表示されます。

問題: PARALLEL モードのパイプラインの場合、パイプライン実行モードを QUEUED または SUPERSED に編集しても、パイプラインの状態には更新された状態が PARALLEL として表示されません。パイプラインが PARALLEL から QUEUED または SUPERSEDED に変更された場合、SUPERSED モードまたは QUEUED モードのパイプラインの状態は、どちらのモードでも最後の既知の状態になります。そのモードでパイプラインを実行したことがない場合、状態は空になります。

解決方法: パラレルモードのパイプラインの場合、パイプライン実行モードを QUEUED または SUPERSED に編集すると、実行モードの表示に PARALLEL 状態は表示されないことに注意してください。

QUEUED または PARALLEL 実行モードの詳細については、「」を参照してくださいCodePipeline の概念

ファイルパスによるトリガーフィルタリングを使用する接続を持つパイプラインは、ブランチの作成時に開始されない場合があります。

説明: ソースアクションなど、接続を使用する BitBucket ソースアクションを持つパイプラインの場合、ファイルパスでフィルタリングしてパイプラインを開始できる Git 設定でトリガーを設定できます。場合によっては、ファイルパスでフィルタリングされたトリガーを持つパイプラインの場合、ファイルパスフィルターを持つブランチが最初に作成されたときにパイプラインが開始されないことがあります。これは、変更されたファイルをAWS CodeStar Connections接続で解決できないためです。トリガーの Git 設定がファイルパスでフィルタリングするように設定されている場合、ソースリポジトリにフィルター付きのブランチが作成された時点でパイプラインが開始されません。ファイルパスでのフィルタリングの詳細については、「」を参照してくださいコードプッシュまたはプルリクエストでトリガーをフィルタリングする

結果: たとえば、ブランチ「B」にファイルパスフィルター CodePipeline がある のパイプラインは、ブランチ「B」の作成時にトリガーされません。ファイルパスフィルターがない場合でも、パイプラインは開始されます。

ファイルパスによるトリガーフィルタリングを使用する接続を持つパイプラインは、ファイル制限に達したときに開始されない場合があります。

説明: ソースアクションなど、接続を使用する BitBucket ソースアクションを含むパイプラインの場合、ファイルパスでフィルタリングしてパイプラインを開始できる Git 設定でトリガーを設定できます。 CodePipeline は、最初の 100 個のファイルを取得します。したがって、トリガーの Git 設定がファイルパスでフィルタリングするように設定されている場合、100 個を超えるファイルがある場合、パイプラインが開始されないことがあります。ファイルパスのフィルタリングの詳細については、「」を参照してくださいコードプッシュまたはプルリクエストでトリガーをフィルタリングする

結果: 例えば、差分に 150 個のファイルが含まれている場合、 CodePipeline は最初の 100 個のファイルを調べて (特定の順序ではない場合)、指定されたファイルパスフィルターと照合します。ファイルパスフィルターに一致するファイルが、 によって取得された 100 ファイルに含まれていない場合 CodePipeline、パイプラインは呼び出されません。

別の問題があるため問い合わせ先を教えてください。

これらの他のリソースを試してください。