翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # CodeBuild のビルド仕様に関するリファレンス このトピックでは、ビルド仕様 (buildspec) ファイルに関する重要なリファレンス情報を提供します。*ビルド環境*は、CodeBuild がビルドを実行するために使用するオペレーティングシステム、プログラミング言語ランタイム、およびツールの組み合わせを表します。buildspec をソースコードの一部として含めることも、ビルドプロジェクトの作成時に buildspec を定義することもできます。ビルド仕様の仕組みについては、「[CodeBuild の仕組み](concepts.md#concepts-how-it-works)」を参照してください。 **Topics** + [buildspec ファイル名とストレージの場所](#build-spec-ref-name-storage) + [buildspec の構文](#build-spec-ref-syntax) + [buildspec の例](#build-spec-ref-example) + [buildspec のバージョン](#build-spec-ref-versions) + [バッチビルドのビルド仕様 (buildspec) のリファレンス](batch-build-buildspec.md) ## buildspec ファイル名とストレージの場所 buildspec をソースコードの一部として含める場合、デフォルトの buildspec ファイルの名前は `buildspec.yml` で、ソースディレクトリのルートに配置する必要があります。 デフォルトの buildspec ファイルの名前と場所を変更することができます。たとえば、以下のことが可能です。 + 同じリポジトリ内の異なるビルドに、`buildspec_debug.yml` や `buildspec_release.yml` などの異なる buildspec ファイルを使用する。 + `config/buildspec.yml` など、ソースディレクトリのルート以外の場所や、S3 バケットに buildspec ファイルを保存する。S3 バケットは、ビルドプロジェクトと同じ AWS リージョンに存在する必要があります。ARN を使用して buildspec ファイルを指定します（例: `arn:aws:s3:::/buildspec.yml`）。 buildspec ファイルの名前に関係なく、ビルドプロジェクトには 1 つの buildspec しか指定できません。 デフォルトの buildspec ファイルの名前、場所、またはその両方をオーバーライドするには、次のいずれかを実行します。 + または `update-project` コマンドを実行し AWS CLI `create-project`、値を組み込み環境変数 の値に対する代替 buildspec ファイルへの`buildspec`パスに設定します`CODEBUILD_SRC_DIR`。 AWS SDKs の `create project`オペレーションと同等の操作を行うこともできます。詳細については、「[ビルドプロジェクトの作成](create-project.md)」または「[ビルドプロジェクト設定を変更](change-project.md)」を参照してください。 + コマンドを実行し AWS CLI `start-build`、 `buildspecOverride` 値を、組み込み環境変数 の値に対する代替 buildspec ファイルへのパスに設定します`CODEBUILD_SRC_DIR`。 AWS SDKs の `start build`オペレーションと同等の操作を行うこともできます。詳細については、「[ビルドを手動で実行](run-build.md)」を参照してください。 + AWS CloudFormation テンプレートで、 タイプのリソース`Source`の `BuildSpec`プロパティ`AWS::CodeBuild::Project`を、組み込み環境変数 の値に対する代替 buildspec ファイルのパスに設定します`CODEBUILD_SRC_DIR`。詳細については、*AWS CloudFormation ユーザーガイド*の[AWS CodeBuild プロジェクトソース](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-codebuild-project-source.html)の BuildSpec プロパティを参照してください。 ## buildspec の構文 buildspec ファイルは [YAML](http://yaml.org/) 形式で表現する必要があります。 YAML でサポートされていない文字または文字列がコマンドに含まれている場合は、そのコマンドを引用符 ("") で囲む必要があります。次のコマンドが引用符で囲まれているのは、YAML ではコロン (:) に続けてスペースを使用できないためです。コマンド内の引用符はエスケープ (\$1") されます。 ``` "export PACKAGE_NAME=$(cat package.json | grep name | head -1 | awk -F: '{ print $2 }' | sed 's/[\",]//g')" ``` buildspec の構文は次のとおりです。 ``` version: 0.2 run-as: Linux-user-name env: shell: shell-tag variables: key: "value" key: "value" parameter-store: key: "value" key: "value" exported-variables: - variable - variable secrets-manager: key: secret-id:json-key:version-stage:version-id git-credential-helper: no | yes proxy: upload-artifacts: no | yes logs: no | yes batch: fast-fail: false | true # build-list: # build-matrix: # build-graph: # build-fanout: phases: install: run-as: Linux-user-name on-failure: ABORT | CONTINUE | RETRY | RETRY-count | RETRY-regex | RETRY-count-regex runtime-versions: runtime: version runtime: version commands: - command - command finally: - command - command pre\$1build: run-as: Linux-user-name on-failure: ABORT | CONTINUE | RETRY | RETRY-count | RETRY-regex | RETRY-count-regex commands: - command - command finally: - command - command build: run-as: Linux-user-name on-failure: ABORT | CONTINUE | RETRY | RETRY-count | RETRY-regex | RETRY-count-regex commands: - command - command finally: - command - command post\$1build: run-as: Linux-user-name on-failure: ABORT | CONTINUE | RETRY | RETRY-count | RETRY-regex | RETRY-count-regex commands: - command - command finally: - command - command reports: report-group-name-or-arn: files: - location - location base-directory: location discard-paths: no | yes file-format: report-format artifacts: files: - location - location name: artifact-name discard-paths: no | yes base-directory: location exclude-paths: excluded paths enable-symlinks: no | yes s3-prefix: prefix secondary-artifacts: artifactIdentifier: files: - location - location name: secondary-artifact-name discard-paths: no | yes base-directory: location artifactIdentifier: files: - location - location discard-paths: no | yes base-directory: location cache: key: key fallback-keys: - fallback-key - fallback-key action: restore | save paths: - path - path ``` buildspec には、次のものが含まれています。 ### バージョン 必要なマッピング。buildspec のバージョンを表します。`0.2` を使用することをお勧めします。 **注記** バージョン 0.1 も引き続きサポートされていますが、可能な場合はバージョン 0.2 を使用することをお勧めします。詳細については、「[buildspec のバージョン](#build-spec-ref-versions)」を参照してください。 ### run-as オプションのシーケンス。Linux ユーザーのみが使用できます。この buildspec ファイルでコマンドを実行する Linux ユーザーを指定します。`run-as` は、指定したユーザーに読み取りおよび実行の許可を付与します。buildspec ファイルの上で `run-as` を指定すると、すべてのコマンドにグローバルに適用されます。すべての buildspec ファイルコマンドのユーザーを指定しない場合、`phases` ブロックのいずれかで `run-as` を使用することによりフェーズでいずれかのコマンドを指定できます。`run-as` を指定しない場合、すべてのコマンドがルートユーザーとして実行されます。 ### env オプションのシーケンス。1 つ以上のカスタム環境変数の情報を表します。 **注記** 機密情報を保護するために、CodeBuild ログでは次の情報が非表示になっています。 AWS アクセスキー IDs。詳細については、*AWS Identity and Access Management ユーザーガイド*の [IAM ユーザーのアクセスキーの管理](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html)を参照してください。 パラメータストアを使用して指定された文字列。詳細については、「*Amazon EC2 Systems Manager ユーザーガイド*」の「[Systems Manager パラメータストア](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-paramstore.html)」および「[Systems Manager パラメータストアコンソールのチュートリアル](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-paramstore-walk.html#sysman-paramstore-console)」を参照してください。 を使用して指定された文字列 AWS Secrets Manager。詳細については、「[キー管理](security-key-management.md)」を参照してください。 env/**shell** オプションのシーケンス。Linux または Windows オペレーティングシステムでサポートされるシェルを指定します。 Linux オペレーティングシステムで、サポートされているシェルタグは次のとおりです。 + `bash` + `/bin/sh` Windows オペレーティングシステムで、サポートされているシェルタグは次のとおりです。 + `powershell.exe` + `cmd.exe` env/**variables** `env` を指定し、プレーンテキストでカスタム環境変数を定義する場合は必須です。*key* と *value* のスカラーのマッピングを含み、各マッピングはプレーンテキストで 1 つのカスタム環境変数を表します。*key* は、カスタム環境変数の名前で、*value* はその変数の値です。 機密の値は環境変数に保存しないことを強くお勧めします。環境変数は、CodeBuild コンソールや AWS CLIなどのツールを使用してプレーンテキストで表示できます。機密情報については、このセクションの後半で説明するように、`parameter-store` マッピングまたは `secrets-manager` マッピングを代わりに使用することをお勧めします。 既存の環境変数は、設定した環境変数によって置き換えられます。たとえば、Docker イメージに `my_value` の値を持つ `MY_VAR` という名前の環境変数が既に含まれていて、`other_value` の値を持つ `MY_VAR` という名前の環境変数を設定した場合、`my_value` が `other_value` に置き換えられます。同様に、Docker イメージに `/usr/local/sbin:/usr/local/bin` の値を持つ `PATH` という名前の環境変数が既に含まれていて、`$PATH:/usr/share/ant/bin` の値を持つ `PATH` という名前の環境変数を設定した場合、`/usr/local/sbin:/usr/local/bin` はリテラル値 `$PATH:/usr/share/ant/bin` に置き換えられます。 `CODEBUILD_` で始まる名前の環境変数は設定しないでください。このプレフィックスは内部使用のために予約されています。 同じ名前の環境変数が複数の場所で定義されている場合は、その値は次のように決定されます。 + ビルド開始オペレーション呼び出しの値が最も優先順位が高くなります。ビルドの作成時に環境変数を追加または上書きできます。詳細については、「[AWS CodeBuild ビルドを手動で実行する](run-build.md)」を参照してください。 + ビルドプロジェクト定義の値が次に優先されます。プロジェクトを作成または編集するときに、プロジェクトレベルで環境変数を追加できます。詳細については、「[でのビルドプロジェクトの作成AWS CodeBuild](create-project.md)」および「[でビルドプロジェクト設定を変更する AWS CodeBuild](change-project.md)」を参照してください。 + ビルド仕様宣言の値の優先順位が最も低くなります。 env/**parameter-store** `env` が指定されていて、Amazon EC2 Systems Manager パラメータストアに保存されているカスタム環境変数を取得する場合は必須です。*key* と *value* のスカラーのマッピングを含み、各マッピングは単一のカスタム環境変数を表し、Amazon EC2 Systems Manager パラメータストアに保存されます。*key* は、後でビルドコマンドで使用するこのカスタム環境変数を参照する名前で、*value* は Amazon EC2 Systems Manager パラメータストアに保存されているカスタム環境変数の名前です。重要な値を保存するには、*Amazon EC2 Systems Manager ユーザーガイド*の「[Systems Manager パラメータストア](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-paramstore.html)」および「[チュートリアル: String パラメータの作成とテスト (コンソール)](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-paramstore-console.html)」を参照してください。 Amazon EC2 Systems Manager パラメータストアに保存されているカスタム環境変数を取得することを CodeBuild に許可するには、CodeBuild サービスロールに `ssm:GetParameters` アクションを追加する必要があります。詳細については、「[CodeBuild が他の AWS サービスとやり取りすることを許可する](setting-up-service-role.md)」を参照してください。 Amazon EC2 Systems Manager パラメータストアから取得する環境変数は、既存の環境変数を置き換えます。たとえば、Docker イメージに `MY_VAR` という名前で値が `my_value` の環境変数がすでに含まれていて、`MY_VAR` という名前で値が `other_value` の環境変数を取得した場合、`my_value` は `other_value` に置き換えられます。同様に、Docker イメージに `/usr/local/sbin:/usr/local/bin` という名前で値が `PATH` の環境変数がすでに含まれていて、`$PATH:/usr/share/ant/bin` という名前で値が `PATH` の環境変数を取得した場合、`/usr/local/sbin:/usr/local/bin` はリテラル値 `$PATH:/usr/share/ant/bin` に置き換えられます。 `CODEBUILD_` で始まる名前の環境変数は保存しないでください。このプレフィックスは内部使用のために予約されています。 同じ名前の環境変数が複数の場所で定義されている場合は、その値は次のように決定されます。 + ビルド開始オペレーション呼び出しの値が最も優先順位が高くなります。ビルドの作成時に環境変数を追加または上書きできます。詳細については、「[AWS CodeBuild ビルドを手動で実行する](run-build.md)」を参照してください。 + ビルドプロジェクト定義の値が次に優先されます。プロジェクトを作成または編集するときに、プロジェクトレベルで環境変数を追加できます。詳細については、「[でのビルドプロジェクトの作成AWS CodeBuild](create-project.md)」および「[でビルドプロジェクト設定を変更する AWS CodeBuild](change-project.md)」を参照してください。 + ビルド仕様宣言の値の優先順位が最も低くなります。 env/**secrets-manager** に保存されているカスタム環境変数を取得する場合に必要です AWS Secrets Manager。次のパターンを使用して、Secrets Manager `reference-key` を指定します。 ``: `:::` ** (必須) ローカル環境変数の名前。この名前を使用して、ビルド中に変数にアクセスします。 ** (必須) シークレットの一意の識別子として機能する名前または Amazon リソースネーム (ARN) です。 AWS アカウントのシークレットにアクセスするには、シークレット名を指定します。別の AWS アカウントのシークレットにアクセスするには、シークレット ARN を指定します。 ** (オプション) 値を取得する Secrets Manager のキーと値のペアのキー名を指定します。`json-key` を指定しない場合、CodeBuild はシークレットテキスト全体を取得します。 ** (オプション) バージョンに添付されているステージングラベルによって取得するシークレットのバージョンを指定します。ステージングラベルは、ローテーション処理中にさまざまなバージョンを追跡するために使用されます。`version-stage` を使用する場合は、`version-id` を指定しないでください。バージョンステージもバージョン ID も指定しない場合、デフォルトでは `AWSCURRENT` のバージョンステージ値でバージョンが取得されます。 ** (オプション) 使用したいシークレットのバージョンの固有 ID を指定します。`version-id` を指定した場合は、`version-stage` を指定しないでください。バージョンステージもバージョン ID も指定しない場合、デフォルトでは `AWSCURRENT` のバージョンステージ値でバージョンが取得されます。 次の例で、`TestSecret` は Secrets Manager に保存されているキーと値のペアの名前です。`TestSecret` のキーは `MY_SECRET_VAR` です。ビルド中に変数にアクセスするには、名前「`LOCAL_SECRET_VAR`」を使用します。 ``` env: secrets-manager: LOCAL_SECRET_VAR: "TestSecret:MY_SECRET_VAR" ``` 詳細については、[AWS Secrets Managerユーザーガイド](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html)の「*AWS Secrets Manager とは?*」を参照してください。 env/**exported-variables** オプションのマッピング。エクスポートする環境変数をリストするために使用します。エクスポートする各変数の名前を、`exported-variables` の別の行で指定します。エクスポートする変数は、ビルド中にコンテナで使用できる必要があります。エクスポートする変数は、環境変数にすることができます。 エクスポートされた環境変数は、 と組み合わせて使用 AWS CodePipeline して、現在のビルドステージからパイプラインの後続のステージに環境変数をエクスポートします。詳細については、*AWS CodePipeline ユーザーガイド*の[変数の操作](https://docs.aws.amazon.com//codepipeline/latest/userguide/actions-variables.html)を参照してください。 ビルド中、変数の値は、`install` フェーズから開始して使用できます。これは、`install` フェーズの開始と `post_build` フェーズの終了の間に更新することができます。`post_build` フェーズが終了すると、エクスポートされた変数の値は変更できません。 以下はエクスポートできません: + ビルドプロジェクトで指定された Amazon EC2 Systems Manager Parameter Store シークレット + ビルドプロジェクトで指定された Secrets Manager のシークレット + `AWS_` で始まる環境変数。 env/**git-credential-helper** オプションのマッピング。CodeBuild が Git 認証情報ヘルパーを使用して Git 認証情報を提供するかどうかを示します。使用する場合は `yes` です。それ以外の場合は、`no` または指定なしです。詳細については、Git ウェブサイトの「[gitcredentials](https://git-scm.com/docs/gitcredentials)」を参照してください。 `git-credential-helper` は、パブリック Git リポジトリの Webhook によってトリガーされるビルドではサポートされません。 ### proxy オプションのシーケンス。明示的なプロキシサーバーでビルドを実行する場合、設定を表すために使用されます。詳細については、「[明示的なプロキシサーバーでの CodeBuild の実行](run-codebuild-in-explicit-proxy-server.md)」を参照してください。 proxy/**upload-artifacts** オプションのマッピング。明示的なプロキシサーバーのビルドでアーティファクトをアップロードする場合は、`yes` に設定します。デフォルトは `no` です。 proxy/**logs** オプションのマッピング。明示的なプロキシサーバーのビルドで、CloudWatch ログを作成するには、`yes` に設定します。デフォルトは `no` です。 ### phases 必要なシーケンス。ビルドの各段階で CodeBuild が実行するコマンドを表します。 **注記** buildspec バージョン 0.1 では、CodeBuild はビルド環境のデフォルトシェルの各インスタンスで各コマンドを実行します。つまり、各コマンドは他のすべてのコマンドとは独立して実行されます。したがって、デフォルトでは、以前のコマンド (ディレクトリの変更や環境変数の設定など) の状態に依存する単一のコマンドを実行することはできません。この制限を回避するには、バージョン 0.2 を使用することをお勧めします。これにより、問題が解決されます。buildspec バージョン 0.1 を使用する必要がある場合は、「[ビルド環境のシェルとコマンド](build-env-ref-cmd.md)」のアプローチをお勧めします。 phases/\$1/**run-as** オプションのシーケンス。ビルドフェーズで使用し、そのコマンドを実行する Linux ユーザーを指定します。buildspec ファイルの上ですべてのコマンドに対して `run-as` もグローバルに指定されている場合、フェーズレベルのユーザーが優先されます。例えば、`run-as` がグローバルに User-1 を指定し、`run-as` ステートメントが `install` フェーズでのみ User-2 を指定した場合、buildspec ファイル内のすべてのコマンドは User-1 として実行されますが、`install` フェーズのコマンドは*除きます* (これらのコマンドは User-2 として実行されます)。 phases/\$1/**on-failure** オプションのシーケンス。フェーズ中に障害が発生した場合に実行するアクションを指定します。これには、次のいずれかの値を指定できます。 + `ABORT` - ビルドを中止します。 + `CONTINUE` - 次のフェーズに進みます。 + `RETRY` - 正規表現 `.*` に一致するエラーメッセージを表示し、ビルドを最大 3 回再試行します。 + `RETRY-count` - 正規表現 `.*` に一致するエラーメッセージを表示し、*count* で表される指定回数ビルドを再試行します。*count* は 0～100 の範囲にする必要があります。例えば、有効な値には `RETRY-4` や `RETRY-8` などがあります。 + `RETRY-regex` - ビルドを最大 3 回再試行し、*regex* を使用して、指定されたエラーメッセージに一致する正規表現を含めます。例えば、有効な値には `Retry-.*Error: Unable to connect to database.*` や `RETRY-invalid+` などがあります。 + `RETRY-count-regex` - *count* で表される指定回数ビルドを再試行します。*count* は 0～100 の範囲にする必要があります。*regex* を使用して、エラーメッセージに一致する正規表現を含めることもできます。例えば、有効な値には `Retry-3-.*connection timed out.*` や `RETRY-8-invalid+` などがあります。 このプロパティを指定しない場合は、[ビルドフェーズの移行](view-build-details-phases.md) に示すように、失敗処理が遷移フェーズに続きます。 Lambda コンピューティングまたはリザーブドキャパシティを使用する場合、`on-failure` 属性はサポートされません。この属性は、CodeBuild が提供する EC2 コンピューティングイメージでのみ機能します。 phases/\$1/**finally** オプションのブロック。`finally` ブロックに指定したコマンドは、`commands` ブロックのコマンドの実行後に実行されます。`finally` ブロックに指定したコマンドは、`commands` ブロックのコマンドが失敗した場合でも実行されます。例えば、`commands` ブロック内に 3 つのコマンドがあり、最初のコマンドが失敗した場合、CodeBuild は残りの 2 つのコマンドをスキップして `finally` ブロック内のコマンドを実行します。`commands` ブロックと `finally` ブロックのすべてのコマンドが正常に実行されると、フェーズは成功します。フェーズのいずれかのコマンドが失敗すると、フェーズは失敗します。 許可されるビルドフェーズ名は次のとおりです。 phases/**install** オプションのシーケンス。インストール時に CodeBuild が実行するコマンドがある場合は、そのコマンドを表します。`install` フェーズは、ビルド環境でのパッケージのインストールにのみ使用することをお勧めします。たとえば、このフェーズを使用して、Mocha や RSpec などのコードテストフレームワークをインストールすることができます。 phases/install/**runtime-versions** オプションのシーケンス。ランタイムバージョンは、Ubuntu 標準イメージ 5.0 以降および Amazon Linux 2 標準イメージ 4.0 以降でサポートされています。指定した場合、少なくとも 1 つのランタイムをこのセクションに含める必要があります。ランタイムを指定するには、特定のバージョンを使用するか、メジャーバージョンに `.x` を続けて CodeBuild がこのメジャーバージョンと最新マイナーバージョンを使用することを指定するか、`latest` を指定して最新のメジャーバージョンとマイナーバージョン (`ruby: 3.2`、`nodejs: 18.x`、`java: latest` など) を使用します。数値または環境変数を使用してランタイムを指定できます。例えば、Amazon Linux 2 標準イメージ 4.0 を使用している場合、次の例は、Java のバージョン 17、Python バージョン 3 の最新マイナーバージョン、および Ruby の環境変数内のバージョンをインストールすることを指定します。詳細については、「[CodeBuild に用意されている Docker イメージ](build-env-ref-available.md)」を参照してください。 ``` phases: install: runtime-versions: java: corretto8 python: 3.x ruby: "$MY_RUBY_VAR" ``` buildspec ファイルの `runtime-versions` セクションで 1 つ以上のランタイムを指定できます。ランタイムが別のランタイムに依存している場合は、依存しているランタイムを buildspec ファイルで指定することもできます。buildspec ファイルでランタイムを指定しない場合は、CodeBuild により、使用するイメージのデフォルトのランタイムが選択されます。1 つ以上のランタイムを指定すると、CodeBuild により、それらのランタイムのみが使用されます。依存関係のあるランタイムが指定されていない場合、CodeBuild により、依存関係のあるランタイムの選択が試みられます。 ランタイムバージョンが指定されていない場合、CodeBuild はデフォルトバージョンを使用します。デフォルトバージョンは、以前のデフォルトバージョンがサポート終了 (EOL) に達すると変更される可能性があります。ビルド環境の予期しない変更を回避するには、buildspec ファイルでランタイムバージョンを指定することをお勧めします。 2 つの指定されたランタイムが競合する場合、ビルドは失敗します。たとえば、`android: 29` と `java: openjdk11` が矛盾するので、両方が指定されている場合は、ビルドは失敗します。 使用できるランタイムの詳細については、「[使用可能なランタイム](available-runtimes.md)」を参照してください。 `runtime-versions` セクションを指定して、Ubuntu 標準イメージ 2.0 以降や Amazon Linux 2 (AL2) 標準イメージ 1.0 以降以外のイメージを使用した場合は、ビルドで「`Skipping install of runtimes. Runtime version selection is not supported by this build image`」の警告が表示されます。 phases/install/**commands** オプションのシーケンス。一連のスカラーが含まれ、各スカラーは、インストール中に CodeBuild が実行する単一のコマンドを表します。CodeBuild は、最初から最後まで、各コマンドを一度に 1 つずつ、指定された順序で実行します。 phases/**pre\$1build** オプションのシーケンス。ビルドの前に CodeBuild が実行するコマンドがあれば、それを表します。たとえば、このフェーズを使用して Amazon ECR にサインインするか、npm の依存関係をインストールすることができます。 phases/pre\$1build/**commands** `pre_build` が指定されている場合は必須のシーケンスです。一連のスカラーが含まれ、各スカラーは、ビルドの前に CodeBuild が実行する単一のコマンドを表します。CodeBuild は、最初から最後まで、各コマンドを一度に 1 つずつ、指定された順序で実行します。 phases/**build** オプションのシーケンス。ビルド中に CodeBuild が実行するコマンドがあれば、それを表します。たとえば、このフェーズを使用して、Mocha、RSpec、または sbt を実行できます。 phases/build/**commands** `build` が指定されている場合は必須です。一連のスカラーが含まれ、各スカラーは、ビルド中に CodeBuild が実行する単一のコマンドを表します。CodeBuild は、最初から最後まで、各コマンドを一度に 1 つずつ、指定された順序で実行します。 phases/**post\$1build** オプションのシーケンス。ビルドの後に CodeBuild が実行するコマンドがあれば、それを表します。たとえば、Maven を使用してビルドアーティファクトを JAR または WAR ファイルにパッケージ化するか、Docker イメージを Amazon ECR にプッシュすることができます。次に、Amazon SNS を介してビルド通知を送信できます。 phases/post\$1build/**commands** `post_build` が指定されている場合は必須です。一連のスカラーが含まれ、各スカラーは、ビルドの後に CodeBuild が実行する単一のコマンドを表します。CodeBuild は、最初から最後まで、各コマンドを一度に 1 つずつ、指定された順序で実行します。 ### ついて **report-group-name-or-arn** オプションのシーケンス。レポートの送信先のレポートグループを指定します。プロジェクトには、最大 5 つのレポートグループを含めることができます。既存のレポートグループの ARN、または新しいレポートグループの名前を指定します。名前を指定した場合、CodeBuild は、プロジェクト名と `-` 形式で指定した名前を使用してレポートグループを作成します。レポートグループ名は、`$REPORT_GROUP_NAME` などの buildspec の環境変数を使用して設定することもできます。詳細については、「[Report group naming](test-report-group-naming.md)」を参照してください。 reports//**files** 必要なシーケンス。レポートによって生成されたテスト結果の生データを含む場所を表します。スカラーのシーケンスが含まれます。各スカラーは、元のビルドの場所または `base-directory` (設定されている場合) を基準にして、CodeBuild がテストファイルを検索できる個別の場所を表します。場所には次のものが含まれます。 + 1 つのファイル (例: `my-test-report-file.json`)。 + サブディレクトリ内の単一のファイル (`my-subdirectory/my-test-report-file.json` や `my-parent-subdirectory/my-subdirectory/my-test-report-file.json` など)。 + `'**/*'` はすべてのファイルを再帰的に表します。 + `my-subdirectory/*` は、*my-subdirectory* という名前のサブディレクトリ内のすべてのファイルを表します。 + `my-subdirectory/**/*` は、*my-subdirectory* という名前のサブディレクトリから再帰的にすべてのファイルを表します。 reports//**file-format** オプションのマッピング。レポートファイル形式を表します。指定しない場合は、`JUNITXML` を使用します。この値は大文字と小文字が区別されません。想定される値は次のとおりです。 **テストレポート** `CUCUMBERJSON` Cucumber JSON `JUNITXML` JUnit XML `NUNITXML` NUnit XML `NUNIT3XML` NUnit 3 XML `TESTNGXML` TestNG XML `VISUALSTUDIOTRX` Visual Studio TRX **コードカバレッジレポート** `CLOVERXML` クローバー XML `COBERTURAXML` Cobertura XML `JACOCOXML` JaCoCo XML `SIMPLECOV` SimpleCov JSON CodeBuild は、[simplecov-json](https://github.com/vicentllongo/simplecov-json) ではなく、[simplecov](https://github.com/simplecov-ruby/simplecov) によって生成された JSON コードカバレッジレポートを受け入れます。 reports//**base-directory** オプションのマッピング。CodeBuild が生のテストファイルを見つける場所を決定するために使用する元のビルド場所に対する相対的な 1 つ以上のトップレベルディレクトリを表します。 reports//**discard-paths** オプション。レポートファイルのディレクトリを出力でフラット化するかどうかを指定します。これが指定されていない場合、または `no` を含む場合、レポートファイルはディレクトリ構造のまま出力されます。このディレクトリに `yes` が含まれている場合、すべてのテストファイルが同じ出力ディレクトリに配置されます。たとえば、テスト結果へのパスが `com/myapp/mytests/TestResult.xml` である場合、`yes` を指定すると、このファイルが `/TestResult.xml` に配置されます。 ### artifacts オプションのシーケンス。CodeBuild がビルド出力を見つけることができる場所に関する情報、CodeBuild が S3 出力バケットへのアップロード用にその出力を準備する方法に関する情報を表します。たとえば、Docker イメージを作成して Amazon ECR にプッシュしている場合、または、ソースコードでユニットテストを実行していてもビルドしていない場合、このシーケンスは必要ありません。 **注記** Amazon S3 メタデータには、`x-amz-meta-codebuild-buildarn` という名前の CodeBuild ヘッダーがあります。このヘッダーには、Amazon S3 にアーティファクトを公開する CodeBuild ビルドの `buildArn` が含まれています。通知のソーストラッキングを許可し、アーティファクトの生成元であるビルドを参照するには、`buildArn` を追加します。 artifacts/**files** 必要なシーケンス。ビルド環境でのビルド出力アーティファクトを含む場所を表します。スカラーのシーケンスが含まれ、各スカラーは、CodeBuild が元のビルドの場所を基準に、あるいは設定されている場合はベースディレクトリを基準にして、ビルド出力アーティファクトを見つけることができる個別の場所を表します。場所には次のものが含まれます。 + 1 つのファイル (例: `my-file.jar`)。 + サブディレクトリ内の単一のファイル (`my-subdirectory/my-file.jar` や `my-parent-subdirectory/my-subdirectory/my-file.jar` など)。 + `'**/*'` はすべてのファイルを再帰的に表します。 + `my-subdirectory/*` は、*my-subdirectory* という名前のサブディレクトリ内のすべてのファイルを表します。 + `my-subdirectory/**/*` は、*my-subdirectory* という名前のサブディレクトリから再帰的にすべてのファイルを表します。 ビルド出力アーティファクトの場所を指定すると、CodeBuild はビルド環境で元のビルドの場所を特定できます。ビルドアーティファクトの出力先の場所に、元のビルドの場所へのパスを追加する、または `./` などで場所を指定する必要はありません。この場所へのパスを知りたい場合は、ビルド中に `echo $CODEBUILD_SRC_DIR` などのコマンドを実行できます。各ビルド環境の場所は多少異なる場合があります。 artifacts/**name** オプション名。ビルドアーティファクトの名前を指定します。この名前は、次のいずれかに該当する場合に使用されます。 + CodeBuild API を使用してビルドを作成し、プロジェクトの更新、プロジェクトの作成、またはビルドの開始時に `ProjectArtifacts` オブジェクトに `overrideArtifactName` フラグを設定した場合。 + CodeBuild コンソールを使用してビルドを作成し、buildspec ファイルで名前を指定して、プロジェクトの作成または更新時に **[Enable semantic versioning]** (セマンティックバージョニングの有効化) を選択した場合。詳細については、「[ビルドプロジェクトの作成 (コンソール)](create-project.md#create-project-console)」を参照してください。 ビルド時に計算される buildspec ファイルの名前を指定できます。buildspec ファイルで指定された名前は、Shell コマンド言語を使用します。たとえば、アーティファクト名に日付と時刻を追加して常に一意にできます。アーティファクト名を一意にすると、アーティファクトが上書きされるのを防ぐことができます。詳細については、「[Shell コマンド言語](http://pubs.opengroup.org/onlinepubs/9699919799/)」を参照してください。 + これは、アーティファクトが作成された日付が付加されたアーティファクト名の例です。 ``` version: 0.2 phases: build: commands: - rspec HelloWorld_spec.rb artifacts: files: - '**/*' name: myname-$(date +%Y-%m-%d) ``` + この例は、CodeBuild 環境変数を使用するアーティファクト名の例です。詳細については、「[ビルド環境の環境変数](build-env-ref-env-vars.md)」を参照してください。 ``` version: 0.2 phases: build: commands: - rspec HelloWorld_spec.rb artifacts: files: - '**/*' name: myname-$AWS_REGION ``` + これは、アーティファクトの作成日が付加された CodeBuild 環境変数を使用するアーティファクト名の例です。 ``` version: 0.2 phases: build: commands: - rspec HelloWorld_spec.rb artifacts: files: - '**/*' name: $AWS_REGION-$(date +%Y-%m-%d) ``` 名前にパス情報を追加して、名前のアーチファクトが名前のパスに基づいてディレクトリに配置されるようにできます。この例では、ビルドアーティファクトは、`builds//my-artifacts` の下に配置されます。 ``` version: 0.2 phases: build: commands: - rspec HelloWorld_spec.rb artifacts: files: - '**/*' name: builds/$CODEBUILD_BUILD_NUMBER/my-artifacts ``` artifacts/**discard-paths** オプション。ビルドアーティファクトのディレクトリが出力でフラット化されるかどうかを指定します。これが指定されていない場合、または `no` を含む場合は、ディレクトリ構造はそのままで、ビルドアーティファクトが出力されます。このディレクトリに `yes` が含まれる場合、すべてのビルドアーティファクトが同じ出力ディレクトリに配置されます。たとえば、ビルド出力アーティファクト内のファイルへのパスが `com/mycompany/app/HelloWorld.java` である場合、`yes` を指定すると、このファイルが `/HelloWorld.java` に配置されます。 artifacts/**base-directory** オプションのマッピング。CodeBuild がビルド出力アーティファクトに含めるファイルとサブディレクトリを決定するために使用する、元のビルドの場所を基準とした、1 つ以上の最上位ディレクトリを表します。有効な値を次に示します。 + 単一の最上位ディレクトリ (例:`my-directory`)。 + `'my-directory*'` `my-directory` で始まる名前を持つすべての最上位ディレクトリを表します。 一致する最上位ディレクトリはビルド出力アーティファクトに含まれず、ファイルとサブディレクトリにのみ含まれます。 `files` および `discard-paths` を使用して、どのファイルとサブディレクトリを含めるかをさらに制限できます。たとえば、以下のようなディレクトリ構造があります。 ``` . ├── my-build-1 │ └── my-file-1.txt └── my-build-2 ├── my-file-2.txt └── my-subdirectory └── my-file-3.txt ``` また、次のような `artifacts` シーケンスがあります。 ``` artifacts: files: - '*/my-file-3.txt' base-directory: my-build-2 ``` 次のサブディレクトリとファイルが、ビルド出力アーティファクトに含まれます。 ``` . └── my-subdirectory └── my-file-3.txt ``` さらに、次のような `artifacts` シーケンスがあります。 ``` artifacts: files: - '**/*' base-directory: 'my-build*' discard-paths: yes ``` 次のファイルが、ビルド出力アーティファクトに含まれます。 ``` . ├── my-file-1.txt ├── my-file-2.txt └── my-file-3.txt ``` artifacts/**exclude-paths** オプションのマッピング。`base-directory` に相対的な 1 つまたは複数のパスを表します。CodeBuild はビルドのアーティファクトから、このパスを除外します。アスタリスク (`*`) 記号は、フォルダの境界を超えない、0 文字以上の名前の要素と一致します。二重アスタリスク (`**`) は、すべてのディレクトリをまたいで、0 文字以上の名前の要素と一致します。 除外パスの例は以下のとおりです。 + すべてのディレクトリからファイルを除外する場合: `"**/file-name/**/*"` + すべてのドットフォルダを除外する場合: `"**/.*/**/*"` + すべてのドットファイルを除外する場合: `"**/.*"` artifacts/**enable-symlinks** オプション。出力タイプが `ZIP` の場合、内部シンボリックリンクを ZIP ファイルに保持するかどうかを指定します。これに `yes` が含まれる場合、ソース内のすべての内部シンボリックリンクがアーティファクト ZIP ファイルに保持されます。 artifacts/**s3-prefix** オプション。アーティファクトを Amazon S3 バケットに出力し、名前空間タイプが `BUILD_ID` の場合に使用するプレフィックスを指定します。使用した場合、バケット内の出力パスは「`//.zip`」となります。 artifacts/**secondary-artifacts** オプションのシーケンス。アーティファクト識別子とアーティファクト定義との間のマッピングとしての 1 つ以上のアーティファクト定義を表します。このブロック内の各アーティファクト識別子は、プロジェクトの `secondaryArtifacts` 属性で定義されたアーティファクトと一致する必要があります。各個別の定義は、上記の `artifacts` ブロックと同じ構文を持っています。 「[`artifacts/files`](#build-spec.artifacts.files)」シーケンスは、セカンダリアーティファクトしか定義されていない場合でも、常に必要です。 たとえば、プロジェクトに次の構造があるとします。 ``` { "name": "sample-project", "secondaryArtifacts": [ { "type": "S3", "location": "", "artifactIdentifier": "artifact1", "name": "secondary-artifact-name-1" }, { "type": "S3", "location": "", "artifactIdentifier": "artifact2", "name": "secondary-artifact-name-2" } ] } ``` 次に、buildspec は次のようになります。 ``` version: 0.2 phases: build: commands: - echo Building... artifacts: files: - '**/*' secondary-artifacts: artifact1: files: - directory/file1 name: secondary-artifact-name-1 artifact2: files: - directory/file2 name: secondary-artifact-name-2 ``` ### キャッシュ オプションのシーケンス。CodeBuild が S3 キャッシュバケットへのキャッシュのアップロード用にファイルを準備できる場所に関する情報を表します。プロジェクトのキャッシュタイプが `No Cache` の場合、このシーケンスは不要です。 cache/**key** オプションのシーケンス。キャッシュを検索または復元するときに使用するプライマリキーを表します。CodeBuild はプライマリキーと完全に一致します。 キーの例を次に示します。 ``` key: npm-key-$(codebuild-hash-files package-lock.json) } ``` cache/**fallback-keys** オプションのシーケンス。プライマリキーを使用してキャッシュが見つからない場合に順次使用されるフォールバックキーのリストを表します。最大 5 つのフォールバックキーがサポートされ、それぞれがプレフィックス検索を使用して照合されます。**key** が指定されていない場合、このシーケンスは無視されます。 フォールバックキーの例を次に示します。 ``` fallback-keys: - npm-key-$(codebuild-hash-files package-lock.json) } - npm-key- - npm- ``` cache/**action** オプションのシーケンス。キャッシュで実行するアクションを指定します。有効な値を次に示します。 + `restore`: 更新を保存せずにキャッシュのみを復元します。 + `save`: 以前のバージョンを復元せずにキャッシュのみを保存します。 値が指定されていない場合、CodeBuild によりデフォルトで復元と保存の両方が実行されます。 cache/**paths** 必要なシーケンス。キャッシュの場所を表します。スカラーのシーケンスが含まれ、各スカラーは、CodeBuild が元のビルドの場所を基準に、あるいは設定されている場合はベースディレクトリを基準にして、ビルド出力アーティファクトを見つけることができる個別の場所を表します。場所には次のものが含まれます。 + 1 つのファイル (例: `my-file.jar`)。 + サブディレクトリ内の単一のファイル (`my-subdirectory/my-file.jar` や `my-parent-subdirectory/my-subdirectory/my-file.jar` など)。 + `'**/*'` はすべてのファイルを再帰的に表します。 + `my-subdirectory/*` は、*my-subdirectory* という名前のサブディレクトリ内のすべてのファイルを表します。 + `my-subdirectory/**/*` は、*my-subdirectory* という名前のサブディレクトリから再帰的にすべてのファイルを表します。 **重要** buildspec 宣言は有効な YAML である必要があるため、buildspec 宣言のスペースは重要です。buildspec の宣言にあるスペースの数が無効な場合、すぐにビルドが失敗する可能性があります。YAML validator を使用して、buildspec の宣言が有効な YAML かどうかをテストできます。 ビルドプロジェクトを作成または更新するときに AWS CLIまたは AWS SDKs を使用して buildspec を宣言する場合、buildspec は YAML 形式で表される単一の文字列で、必要な空白文字と改行エスケープ文字を含める必要があります。次のセクションに例があります。 buildspec.yml ファイルの代わりに CodeBuild または AWS CodePipeline コンソールを使用する場合は、 `build`フェーズのコマンドのみを挿入できます。上記の構文を使用する代わりに、ビルドフェーズで実行するすべてのコマンドを 1 行に記載します。複数のコマンドについては、`&&` で各コマンドを区切ります (例: `mvn test && mvn package`)。 buildspec.yml ファイルの代わりに CodeBuild または CodePipeline コンソールを使用して、ビルド環境でビルド出力アーティファクトの場所を指定することができます。上記の構文を使用する代わりに、すべての場所を 1 行に記載します。複数の場所の場合は、各場所をコンマで区切ります (例: `buildspec.yml, target/my-app.jar`)。 ## buildspec の例 buildspec.yml ファイルの例を次に示します。 ``` version: 0.2 env: variables: JAVA_HOME: "/usr/lib/jvm/java-8-openjdk-amd64" parameter-store: LOGIN_PASSWORD: /CodeBuild/dockerLoginPassword phases: install: commands: - echo Entered the install phase... - apt-get update -y - apt-get install -y maven finally: - echo This always runs even if the update or install command fails pre_build: commands: - echo Entered the pre_build phase... - docker login -u User -p $LOGIN_PASSWORD finally: - echo This always runs even if the login command fails build: commands: - echo Entered the build phase... - echo Build started on `date` - mvn install finally: - echo This always runs even if the install command fails post_build: commands: - echo Entered the post_build phase... - echo Build completed on `date` reports: arn:aws:codebuild:your-region:your-aws-account-id:report-group/report-group-name-1: files: - "**/*" base-directory: 'target/tests/reports' discard-paths: no reportGroupCucumberJson: files: - 'cucumber/target/cucumber-tests.xml' discard-paths: yes file-format: CUCUMBERJSON # default is JUNITXML artifacts: files: - target/messageUtil-1.0.jar discard-paths: yes secondary-artifacts: artifact1: files: - target/artifact-1.0.jar discard-paths: yes artifact2: files: - target/artifact-2.0.jar discard-paths: yes cache: paths: - '/root/.m2/**/*' ``` または AWS SDKs で使用する 1 つの文字列として表される前述の buildspec の例 AWS CLIを次に示します。 ``` "version: 0.2\n\nenv:\n variables:\n JAVA_HOME: \"/usr/lib/jvm/java-8-openjdk-amd64\\"\n parameter-store:\n LOGIN_PASSWORD: /CodeBuild/dockerLoginPassword\n phases:\n\n install:\n commands:\n - echo Entered the install phase...\n - apt-get update -y\n - apt-get install -y maven\n finally:\n - echo This always runs even if the update or install command fails \n pre_build:\n commands:\n - echo Entered the pre_build phase...\n - docker login -u User -p $LOGIN_PASSWORD\n finally:\n - echo This always runs even if the login command fails \n build:\n commands:\n - echo Entered the build phase...\n - echo Build started on `date`\n - mvn install\n finally:\n - echo This always runs even if the install command fails\n post_build:\n commands:\n - echo Entered the post_build phase...\n - echo Build completed on `date`\n\n reports:\n reportGroupJunitXml:\n files:\n - \"**/*\"\n base-directory: 'target/tests/reports'\n discard-paths: false\n reportGroupCucumberJson:\n files:\n - 'cucumber/target/cucumber-tests.xml'\n file-format: CUCUMBERJSON\n\nartifacts:\n files:\n - target/messageUtil-1.0.jar\n discard-paths: yes\n secondary-artifacts:\n artifact1:\n files:\n - target/messageUtil-1.0.jar\n discard-paths: yes\n artifact2:\n files:\n - target/messageUtil-1.0.jar\n discard-paths: yes\n cache:\n paths:\n - '/root/.m2/**/*'" ``` CodeBuild または CodePipeline コンソールで使用する `build` フェーズのコマンドの例を次に示します。 ``` echo Build started on `date` && mvn install ``` これらの例では: + `JAVA_HOME` のキーと `/usr/lib/jvm/java-8-openjdk-amd64` の値を持つプレーンテキストのカスタム環境変数が設定されます。 + Amazon EC2 Systems Manager パラメータストアに保存した `dockerLoginPassword` というカスタム環境変数は、後で `LOGIN_PASSWORD` キーを使用してビルドコマンドで参照します。 + これらのビルドフェーズ名は変更できません。この例で実行されるコマンドは、`apt-get update -y` と `apt-get install -y maven` (Apache Maven をインストールする)、`mvn install` (ソースコードをコンパイル、テストして、ビルド出力アーティファクトにパッケージ化し、ビルド出力アーティファクトを内部リポジトリにインストールする)、`docker login` (Amazon EC2 Systems Manager パラメータストアで設定したカスタム環境変数 `dockerLoginPassword` の値に対応するパスワードを使用して Docker へサインインする)、およびいくつかの `echo` コマンドです。これらの `echo` コマンドは、CodeBuild がコマンドを実行する方法と、コマンドの実行順序を示すためにここに含めています。 + `files` はビルド出力場所にアップロードするファイルを表します。この例では、CodeBuild が 1 つのファイル「`messageUtil-1.0.jar`」をアップロードします。`messageUtil-1.0.jar` ファイルは、ビルド環境の `target` という名の相対ディレクトリ内にあります。`discard-paths: yes` が指定されたため、`messageUtil-1.0.jar` は直接アップロードされます (中間の `target` ディレクトリにはアップロードされません)。ファイル名 `messageUtil-1.0.jar` および相対ディレクトリ名 `target` は、Apache Maven がこの例のビルド出力アーティファクトを作成して保存する方法にのみ基づいています。独自のシナリオでは、これらのファイル名とディレクトリは異なります。 + `reports`は、ビルド中にレポートを生成する 2 つのレポートグループを表します。 + `arn:aws:codebuild:your-region:your-aws-account-id:report-group/report-group-name-1` は、レポートグループの ARN を指定します。テストフレームワークによって生成されたテスト結果は、`target/tests/reports` ディレクトリにあります。ファイル形式は `JunitXml` であり、パスはテスト結果を含むファイルから削除されません。 + `reportGroupCucumberJson` は、新しいレポートグループを指定します。プロジェクトの名前が `my-project` の場合、ビルドの実行時に `my-project-reportGroupCucumberJson` という名前のレポートグループが作成されます。テストフレームワークによって生成されたテスト結果は、`cucumber/target/cucumber-tests.xml` にあります。テストファイルの形式は、`CucumberJson` で、テスト結果を含むファイルからパスが削除されます。 ## buildspec のバージョン 次の表に、buildspec のバージョンとバージョン間の変更を示します。 | バージョン | 変更 | | --- | --- | | 0.2 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/build-spec-ref.html) | | 0.1 | これは、ビルド仕様形式の最初の定義です。 | # バッチビルドのビルド仕様 (buildspec) のリファレンス このトピックでは、バッチビルドプロパティの ビルド仕様 (buildspec) リファレンスを示します。 ## バッチ オプションのマッピング。プロジェクトのバッチビルド設定。 batch/**fast-fail** オプション。1 つ以上のビルドタスクが失敗した場合のバッチビルドの動作を指定します。 `false` デフォルト値。実行中のすべてのビルドが完了します。 `true` ビルドタスクの 1 つが失敗すると、実行中のすべてのビルドが停止します。 デフォルトでは、すべてのバッチビルドタスクは、buildspec ファイルで指定された、`env` や `phases` などのビルド設定で実行されます。デフォルトのビルド設定をオーバーライドするには、「`env`」値または別の buildspec ファイルを「`batch//buildspec`」パラメータで指定します。 `batch` プロパティの内容は、指定されたバッチビルドのタイプによって異なります。可能なバッチビルドタイプは次のとおりです。 + [`batch/build-graph`](#build-spec.batch.build-graph) + [`batch/build-list`](#build-spec.batch.build-list) + [`batch/build-matrix`](#build-spec.batch.build-matrix) + [`batch/build-fanout`](#build-spec.batch.build-fanout) ## `batch/build-graph` *ビルドグラフ*を定義します。ビルドグラフは、バッチ内の他のタスクに依存する一連のタスクを定義します。詳細については、「[ビルドグラフ](batch-build.md#batch_build_graph)」を参照してください。 この要素には、ビルドタスクの配列が含まれます。各ビルドタスクには、以下のプロパティが含まれます。 **ID** 必須。タスクの識別子。 **buildspec** オプション。このタスクに使用する buildspec ファイルのパスとファイル名。このパラメータを指定しないと、現在の buildspec ファイルが使用されます。 **debug-session** オプション。セッションデバッグがこのバッチビルドで有効かどうかを示す、ブール値。セッションデバッグの詳細については、「[Session Manager を使用してビルドをデバッグする](session-manager.md)」を参照してください。 `false` セッションデバッグは無効です。 `true` セッションデバッグは有効です。 **depend-on** オプション。このタスクが依存するタスク識別子の配列。このタスクは、これらのタスクが完了するまで実行されません。 **env** オプション。タスクのビルド環境がオーバーライドされます。次のプロパティが含まれています。 **compute-type** タスクに使用するコンピューティングタイプの識別子。指定できる値については、「[ビルド環境のコンピューティングモードおよびタイプ](build-env-ref-compute-types.md)」の「**computeType**」を参照してください。 ** フリート** タスクに使用するフリートの識別子。詳細については、「[リザーブドキャパシティキャパシティフリートでビルドを実行](fleets.md)」を参照してください。 **画像** タスクに使用するイメージの識別子。指定できる値については、「[CodeBuild に用意されている Docker イメージ](build-env-ref-available.md)」の「**イメージ識別子**」を参照してください。 **privileged-mode** Docker コンテナ内の Docker デーモンを実行するかどうかを示すブール値。ビルドプロジェクトを使用して Docker イメージをビルドする場合にのみ、`true` に設定します。そうしないと、Docker デーモンとやり取りしようとするビルドは失敗します。デフォルトの設定は、`false` です。 **\$1type** タスクに使用する環境タイプの識別子です。指定できる値については、「[ビルド環境のコンピューティングモードおよびタイプ](build-env-ref-compute-types.md)」の「**環境タイプ**」を参照してください。 **variables** ビルド環境に存在する環境変数。詳細については「[env/variables](build-spec-ref.md#build-spec.env.variables)」を参照してください。 **compute-type** と **fleet** は、単一のビルドの同じ識別子では指定できないことに注意してください。 **ignore-failure** オプション。このビルドタスクの失敗を無視できるかどうかを示すブール値。 `false` デフォルト値。このビルドタスクが失敗すると、バッチビルドが失敗します。 `true` このビルドタスクが失敗した場合でも、バッチビルドが成功します。 ビルドグラフの buildspec エントリの例を次に示します。 ``` batch: fast-fail: false build-graph: - identifier: build1 env: variables: BUILD_ID: build1 ignore-failure: false - identifier: build2 buildspec: build2.yml env: variables: BUILD_ID: build2 depend-on: - build1 - identifier: build3 env: variables: BUILD_ID: build3 depend-on: - build2 - identifier: build4 env: compute-type: ARM_LAMBDA_1GB - identifier: build5 env: fleet: fleet_name ``` ## `batch/build-list` *ビルドリスト*を定義します。ビルドリストは、並行して実行されるタスクの数を定義するために使用されます。詳細については、「[ビルドリスト](batch-build.md#batch_build_list)」を参照してください。 この要素には、ビルドタスクの配列が含まれます。各ビルドタスクには、以下のプロパティが含まれます。 **ID** 必須。タスクの識別子。 **buildspec** オプション。このタスクに使用する buildspec ファイルのパスとファイル名。このパラメータを指定しないと、現在の buildspec ファイルが使用されます。 **debug-session** オプション。セッションデバッグがこのバッチビルドで有効かどうかを示す、ブール値。セッションデバッグの詳細については、「[Session Manager を使用してビルドをデバッグする](session-manager.md)」を参照してください。 `false` セッションデバッグは無効です。 `true` セッションデバッグは有効です。 **env** オプション。タスクのビルド環境がオーバーライドされます。次のプロパティが含まれています。 **compute-type** タスクに使用するコンピューティングタイプの識別子。指定できる値については、「[ビルド環境のコンピューティングモードおよびタイプ](build-env-ref-compute-types.md)」の「**computeType**」を参照してください。 ** フリート** タスクに使用するフリートの識別子。詳細については「[リザーブドキャパシティキャパシティフリートでビルドを実行](fleets.md)」を参照してください。 **画像** タスクに使用するイメージの識別子。指定できる値については、「[CodeBuild に用意されている Docker イメージ](build-env-ref-available.md)」の「**イメージ識別子**」を参照してください。 **privileged-mode** Docker コンテナ内の Docker デーモンを実行するかどうかを示すブール値。ビルドプロジェクトを使用して Docker イメージをビルドする場合にのみ、`true` に設定します。そうしないと、Docker デーモンとやり取りしようとするビルドは失敗します。デフォルトの設定は、`false` です。 **\$1type** タスクに使用する環境タイプの識別子です。指定できる値については、「[ビルド環境のコンピューティングモードおよびタイプ](build-env-ref-compute-types.md)」の「**環境タイプ**」を参照してください。 **variables** ビルド環境に存在する環境変数。詳細については「[env/variables](build-spec-ref.md#build-spec.env.variables)」を参照してください。 **compute-type** と **fleet** は、単一のビルドの同じ識別子では指定できないことに注意してください。 **ignore-failure** オプション。このビルドタスクの失敗を無視できるかどうかを示すブール値。 `false` デフォルト値。このビルドタスクが失敗すると、バッチビルドが失敗します。 `true` このビルドタスクが失敗しても、バッチビルドは成功します。 buildspec エントリの例を次に示します。 ``` batch: fast-fail: false build-list: - identifier: build1 env: variables: BUILD_ID: build1 ignore-failure: false - identifier: build2 buildspec: build2.yml env: variables: BUILD_ID: build2 ignore-failure: true - identifier: build3 env: compute-type: ARM_LAMBDA_1GB - identifier: build4 env: fleet: fleet_name - identifier: build5 env: compute-type: GENERAL_LINUX_XLAGRE ``` ## `batch/build-matrix` *ビルドマトリックス*を定義します。ビルドマトリックスは、並行して実行される異なる構成のタスクを定義します。CodeBuild は、設定可能な組み合わせごとに個別のビルドを作成します。詳細については、「[ビルドマトリックス](batch-build.md#batch_build_matrix)」を参照してください。 **static** 静的プロパティは、すべてのビルドタスクに適用されます。 **ignore-failure** オプション。このビルドタスクの失敗を無視できるかどうかを示すブール値。 `false` デフォルト値。このビルドタスクが失敗すると、バッチビルドが失敗します。 `true` このビルドタスクが失敗しても、バッチビルドは成功します。 **env** オプション。ビルド環境はすべてのタスクに対して上書きされます。 **privileged-mode** Docker コンテナ内の Docker デーモンを実行するかどうかを示すブール値。ビルドプロジェクトを使用して Docker イメージをビルドする場合にのみ、`true` に設定します。そうしないと、Docker デーモンとやり取りしようとするビルドは失敗します。デフォルトの設定は、`false` です。 **\$1type** タスクに使用する環境タイプの識別子です。指定できる値については、「[ビルド環境のコンピューティングモードおよびタイプ](build-env-ref-compute-types.md)」の「**環境タイプ**」を参照してください。 **dynamic** 動的プロパティはビルドマトリックスを定義します。 **buildspec** オプション。これらのタスクに使用する buildspec ファイルのパスとファイル名を含む配列。このパラメータを指定しないと、現在の buildspec ファイルが使用されます。 **env** オプション。これらのタスクでは、ビルド環境が上書きされます。 **compute-type** これらのタスクに使用するコンピューティングタイプの識別子を含む配列。指定できる値については、「[ビルド環境のコンピューティングモードおよびタイプ](build-env-ref-compute-types.md)」の「**computeType**」を参照してください。 **画像** これらのタスクに使用するイメージの識別子を含む配列。指定できる値については、「[CodeBuild に用意されている Docker イメージ](build-env-ref-available.md)」の「**イメージ識別子**」を参照してください。 **variables** これらのタスクのビルド環境に存在する環境変数を含む配列。詳細については、「[env/variables](build-spec-ref.md#build-spec.env.variables)」を参照してください。 ビルドマトリックス「buildspec」のエントリの例を次に示します。 ``` batch: build-matrix: static: ignore-failure: false dynamic: buildspec: - matrix1.yml - matrix2.yml env: variables: MY_VAR: - VALUE1 - VALUE2 - VALUE3 ``` 詳細については、「[ビルドマトリックス](batch-build.md#batch_build_matrix)」を参照してください。 ## `batch/build-fanout` *ビルドファンアウト*を定義します。ビルドファンアウトは、並行して実行される複数のビルドに分割されるタスクを定義するために使用されます。詳細については、「[バッチビルドで並列テストを実行する](parallel-test.md)」を参照してください。 この要素には、複数のビルドに分割できるビルドタスクが含まれています。`build-fanout` セクションには、以下のプロパティが含まれています。 **parallelism** 必須。テストを並行して実行するビルドの数。 **ignore-failure** オプション。いずれかのファンアウトビルドタスクで発生した失敗を無視できるかどうかを示すブール値。**ignore-failure** のこの値は、すべてのファンアウトビルドに適用されます。 **'`false**`' デフォルト値。いずれかのファンアウトビルドタスクが失敗すると、バッチビルドが失敗します。 **true** いずれかののビルドタスクが失敗した場合でも、バッチビルドが成功します。 ビルドファンアウト buildspec エントリの例を次に示します。 ``` version: 0.2 batch: fast-fail: false build-fanout: parallelism: 5 ignore-failure: false phases: install: commands: - npm install build: commands: - mkdir -p test-results - cd test-results - | codebuild-tests-run \ --test-command 'npx jest --runInBand --coverage' \ --files-search "codebuild-glob-search '**/test/**/*.test.js'" \ --sharding-strategy 'equal-distribution' ``` 詳細については、「[ビルドファンアウト](batch-build.md#batch_build_fanout)」および「[CLI コマンド `codebuild-tests-run` を使用する](parallel-test-tests-run.md)」を参照してください。