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

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

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

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

トピック

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

問題： 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 のサービスロールには CodeCommit に対する十分な権限がなく、CodeCommit リポジトリを使用するためのサポートが、2016 年 4 月 18 日に追加される前に作成された可能性があります。この日付より前にサービスロールを作成したお客様は、サービスロールのポリシーステートメントを変更して必要なアクセス権限を追加する必要があります。

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

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

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

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

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

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

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

解決方法： アーティファクトが保存されている 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 で表示すると、名前が切り詰められているように見えます。これにより、複数の名前が同じように表示されたり、パイプライン名全体の表示が失われたりしたように見えます。

説明: CodePipeline はアーティファクト名を切り詰めることにより、CodePipeline でジョブワーカーの一時的な認証情報を生成するときに、Amazon S3 のフルパスがポリシーサイズの上限を超えないようにします。

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

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

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

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

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

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

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

コンソールを使用して UseConnection のアクセス許可を追加するには

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

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

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

  2. CodeBuild サービスロールを確認するには、パイプラインで使用されているビルドプロジェクトを開き、[Build details] (ビルドの詳細) タブに移動します。

  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 サービスロールを確認するには、パイプラインで使用されているビルドプロジェクトを開き、[Build details] (ビルドの詳細) タブに移動します。

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

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

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

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

  5. [ポリシーの確認] を選択します。ポリシーの名前 (例: codecommit-gitpull) を入力し、[ポリシーの作成] を選択します。

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

パイプラインのエラー: CodeDeployToECS アクションがあるデプロイから、「<source artifact name> からタスク定義アーティファクトファイルを読み取ろうとしたときに例外が発生しました」というエラーメッセージが返されます。

問題:

タスク定義ファイルは、CodePipeline から Amazon ECS へのデプロイアクション (CodeDeployToECS アクション) に必要なアーティファクトです。CodeDeployToECS デプロイアクションのアーティファクト ZIP の最大サイズは 3 MB です。ファイルが見つからないかアーティファクトのサイズが 3 MB を超える場合は、次のエラーメッセージが返されます。

<source artifact name> からタスク定義アーティファクトファイルを読み取ろうとしたときに例外が発生しました

解決方法: タスク定義ファイルがアーティファクトとして含まれていることを確認してください。そのファイルが既に存在する場合は、圧縮サイズが 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 を参照してください。

Amazon S3 エラー: CodePipeline サービスロール <ARN> により、S3 バケット <BucketName> に対する 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 (コンソール) を表示します。」を参照してください。サービスロールのポリシーステートメントを編集するには「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. [Save] を選択します。

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

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 または を使用して AWS CloudFormation 、変更検出イベントルールを作成および更新します。S3 ソースアクションのイベントルールを作成する手順については、「EventBridge と を使用する Amazon S3 ソースアクションへの接続 AWS CloudTrail」を参照してください。Amazon ECR アクションのイベントルールを作成する手順については、「 Amazon ECR ソースアクションと EventBridge リソース」を参照してください。CodeCommit アクションのイベントルールを作成する手順については、「 CodeCommit ソースアクションと EventBridge」を参照してください。

コンソールでアクション設定を 編集した後、コンソールによって作成された更新された変更検出リソースを 容認します。

GitHub への接続時の Connections エラー:「問題が発生しました。ブラウザで Cookie が有効になっていることを確認してください」または「組織の所有者は GitHub アプリケーションをインストールする必要があります」

問題:

CodePipeline で GitHub ソースアクション用に接続を作成するには、GitHub 組織の所有者であることが必要です。組織のリポジトリではない場合、ユーザーがリポジトリの所有者である必要があります。接続の作成者が組織の所有者以外である場合、組織の所有者へのリクエストが作成され、次のエラーのいずれかが表示されます。

問題が発生しました。ブラウザで Cookie が有効になっていることを確認してください

または

組織の所有者は GitHub アプリケーションをインストールする必要があります

解決策: GitHub 組織のリポジトリである場合、組織の所有者が GitHub リポジトリへの接続を作成する必要があります。組織のリポジトリでない場合、ユーザーがリポジトリの所有者である必要があります。

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

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

可能な修正: 実行モードのパイプライン定義を編集するときは、他の編集アクションとは別に編集を行います。

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

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

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

考えられる修正: 並列モードのパイプラインの場合、パイプライン実行モードを 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 個のファイル (特定の順序なし) を取得し、指定したファイルパスフィルターと照合します。ファイルパスフィルターと一致するファイルが CodePipeline が取得した 100 個のファイルに含まれていない場合、パイプラインは呼び出されません。

PARALLEL モードの CodeCommit または S3 ソースリビジョンは、EventBridge イベントと一致しない可能性があります

説明: PARALLEL モードのパイプライン実行の場合、実行は CodeCommit リポジトリコミットなどの最新の変更で開始する場合があり、これは EventBridge イベントの変更とは異なることがあります。パイプラインを開始するコミット間やイメージタグ間に一瞬の差がある場合、CodePipeline がイベントを受信して実行を開始するときに、別のコミットやイメージタグがプッシュされると、CodePipeline (CodeCommit アクションなど) はその時点で HEAD コミットをクローンします。

結果: PARALLEL モードのパイプラインに CodeCommit または S3 ソースがある場合、パイプライン実行をトリガーした変更に関係なく、ソースアクションは常に開始時に HEAD をクローンします。例えば、PARALLEL モードのパイプラインの場合、コミットをプッシュすると、実行 1 のパイプラインが開始し、2 番目のパイプライン実行で 2 番目のコミットが使用されます。

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

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