トラブルシューティング CodePipeline - AWS CodePipeline
パイプラインのエラー: AWS Elastic Beanstalk で設定されたパイプラインは次のようなエラーメッセージを返します。「デプロイに失敗しました。指定されたロールには、十分なアクセス許可がありません: サービス：AmazonElasticLoadBalancing」デプロイエラー: AWS Elastic Beanstalk デプロイアクションで設定されたパイプラインは、「」アクセスDescribeEvents許可がない場合に失敗するのではなくハングしますパイプラインエラー: ソースアクションは、 CodeCommit 「リポジトリ にアクセスできませんでした」というアクセス許可不足のメッセージを返しますrepository-name。パイプラインIAMロールにリポジトリにアクセスするための十分なアクセス許可があることを確認してください。」パイプラインのエラー: Jenkins のビルドまたはテストアクションが長期間実行された後、認証情報やアクセス許可の不足のため失敗します。パイプラインエラー: 別の AWS リージョンで作成されたバケットを使用してある AWS リージョンで作成されたパイプラインは、「」というコードInternalErrorで「」を返しますJobFailed。デプロイエラー: ZIP ファイルを含むWARファイルは に正常にデプロイされましたが AWS Elastic Beanstalk、アプリケーションは 404 が見つかりませんエラーURLを報告しますパイプラインのアーティファクトフォルダ名が切り詰められているように見えます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 アプリをインストールする必要があります」実行モードが に変更されたパイプライン、QUEUEDまたは実行制限に達するとPARALLELモードが失敗するパイプラインモードのパイプラインは、 PARALLEL QUEUEDまたは SUPERSEDED モードに変更したときに編集された場合、古いパイプライン定義になります。モードから変更されたパイプラインPARALLELには、以前の実行モードが表示されます。ファイルパスによるトリガーフィルタリングを使用する接続を持つパイプラインは、ブランチの作成時に開始されない場合がありますファイルパスによるトリガーフィルタリングを使用する接続を持つパイプラインは、ファイル制限に達したときに開始されない場合がありますCodeCommit または PARALLEL モードの S3 ソースリビジョンが EventBridge イベントと一致しない可能性があります 別の問題があるため問い合わせ先を教えてください。

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

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

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

トピック

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

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

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

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

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

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

問題： のサービスロールには、 を使用するパイプラインの "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。Jenkins サーバー、オンプレミスインスタンス、または必要なIAMロールなしで作成された Amazon EC2インスタンスでIAMユーザーを使用している場合、IAMユーザーには必要なアクセス許可がないか、Jenkins サーバーはサーバーで設定されたプロファイルを介してこれらの認証情報にアクセスできません。

解決方法： Amazon EC2インスタンスのロールまたはIAMユーザーが AWSCodePipelineCustomActionAccessマネージドポリシーまたは同等のアクセス許可で設定されていることを確認します。詳細については、「AWS の マネージドポリシー AWS CodePipeline」を参照してください。

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

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

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

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

デプロイエラー: ZIP ファイルを含むWARファイルは に正常にデプロイされましたが AWS Elastic Beanstalk、アプリケーションは 404 が見つかりませんエラーURLを報告します

問題： WARファイルが AWS Elastic Beanstalk 環境に正常にデプロイされましたが、アプリケーションが 404 Not Found エラーURLを返します。

解決方法： AWS Elastic Beanstalk ZIP ファイルを解凍できますが、WARファイルに含まれるZIPファイルは解凍できません。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 Enterprise Server GitHub、または GitLab.com への接続の CodeBuild GitClone アクセス許可を追加する

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

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

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

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

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

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

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

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

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

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

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

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

    次のサンプルポリシーテンプレートを使用します。この例に示すように、 ARN Resource フィールドに接続を追加します。

    {
    "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 ( アクション) ECSを介して Amazon に 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、接続を作成するには、リポジトリに対する組織所有者のアクセス許可または管理者のアクセス許可が必要です。

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

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. [Save] を選択します。

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

Amazon S3、Amazon 、ECRまたは CodeCommitソースを持つパイプラインは自動的に起動しなくなりました

問題:

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

のパラメータ名の末尾にある軽微な変更の例は、 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 リポジトリへの接続を作成する必要があります。組織のリポジトリでない場合、ユーザーがリポジトリの所有者である必要があります。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

説明： PARALLELモードでのパイプライン実行の場合、実行は CodeCommit リポジトリコミットなどの最新の変更で開始され、 EventBridge イベントの変更と同じではない可能性があります。場合によっては、パイプラインを開始するコミットまたはイメージタグの間に分割秒がある場合、 が CodePipelineイベントを受信してその実行を開始すると、別のコミットまたはイメージタグがプッシュされ CodePipeline ( CodeCommit アクションなど）、その時点でHEADコミットのクローンが作成されます。

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

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

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