トラブルシューティング CodePipeline - AWS CodePipeline
パイプラインのエラー: AWS Elastic Beanstalk で設定されたパイプラインは次のようなエラーメッセージを返します。「デプロイに失敗しました。指定されたロールには十分なアクセス許可がありません: サービス：AmazonElasticLoadBalancing「デプロイエラー：DescribeEvents「」アクセス許可がない場合、 AWS Elastic Beanstalk デプロイアクションで設定されたパイプラインが失敗するのではなくハングしますパイプラインエラー: ソースアクションは、 CodeCommit 「リポジトリ にアクセスできませんでした」という不十分なアクセス許可メッセージを返しますrepository-name。パイプラインIAMロールにリポジトリにアクセスするための十分なアクセス許可があることを確認します。」パイプラインのエラー: Jenkins のビルドまたはテストアクションが長期間実行された後、認証情報やアクセス許可の不足のため失敗します。パイプラインエラー: 別の AWS リージョンで作成されたバケットを使用してある AWS リージョンで作成されたパイプラインは、「」コードでJobFailedInternalError「」を返しますデプロイエラー: 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 バケットの S3 アクセスを拒否されました <BucketName＞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 を使用するパイプラインを手動で再実行します。

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

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

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

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

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

問題： 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 コンソールで、ポリシーのアタッチ を選択し、ポリシーの作成 を選択します。

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

    {
    "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-an-organization」を参照してください。 GitHub

Amazon S3 エラー： CodePipeline サービスロール <ARN> が S3 バケットの S3 アクセスを拒否されました <BucketName＞

問題:

進行中、 の 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。パイプラインが から PARALLELQUEUEDまたは に変更された場合SUPERSEDED、 SUPERSEDED または QUEUEDモードでのパイプラインの状態は、これらのモードのいずれかで最後に知られている状態になります。パイプラインがこのモードで実行されたことがない場合は、状態は空になります。

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

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

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

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

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

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

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

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

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

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

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

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

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