ビルドプロジェクトの作成 (コンソール) - AWS CodeBuild

ビルドプロジェクトの作成 (コンソール)

Open the AWS CodeBuild console at https://console.aws.amazon.com/codesuite/codebuild/home.

If a CodeBuild information page is displayed, choose Create build project. Otherwise, on the navigation pane, expand Build, choose Build projects, and then choose Create build project.

[Create build project (ビルドプロジェクトの作成)] を選択します。

以下のセクションに入力します。完了したら、ページの下部にある [Create build project (ビルドプロジェクトの作成)] を選択します。

プロジェクト設定

Project name

このビルドプロジェクトの名前を入力します。ビルドプロジェクト名は、各 AWS アカウントで一意である必要があります。

 説明

ビルドプロジェクトのオプションの説明を入力して、このプロジェクトがが既に使用されていることを他のユーザーに伝えます。

ビルドバッジ

プロジェクトのビルドステータスを表示可能および埋め込み可能にする場合に選択します。詳細については、ビルドバッジサンプル を参照してください。

注記

ソースプロバイダーが Amazon S3 の場合、ビルドバッジは適用されません。

追加情報

(オプション) [タグ] に、サポート対象の AWS のサービスで使用するタグの名前と値を入力します。[Add row] を使用して、タグを追加します。最大 50 個のタグを追加できます。

Source

ソースプロバイダー

ソースコードプロバイダーのタイプを選択します。次のリストを使用して、ソースプロバイダーに適切な選択を行います。

注記

CodeBuild does not support Bitbucket Server.

Amazon S3
バケット

ソースコードが含まれている入力バケットの名前を選択します。

S3 オブジェクトキーまたは S3 フォルダ

ZIP ファイルの名前、またはソースコードを含むフォルダへのパスを入力します。S3 バケットの中身をすべてダウンロードするには、スラッシュ記号 (/) を入力します。

ソースバージョン

入力ファイルのビルドを表すオブジェクトのバージョン ID を入力します。詳細については、「AWS CodeBuild のソースバージョンのサンプル」を参照してください。

CodeCommit
リポジトリ

使用するリポジトリを選択します。

リファレンスタイプ

[ブランチ]、[Git タグ]、または [コミット ID] を選択して、ソースコードのバージョンを指定します。詳細については、「AWS CodeBuild のソースバージョンのサンプル」を参照してください。

Git のクローンの深さ

指定されたコミット数で切り捨てられる履歴の浅いクローンの作成を選択します。完全クローンを希望する場合には、[Full (完全)] を選択します。

Git サブモジュールを使用する

リポジトリに Git サブモジュールを含める場合を選択します。

Bitbucket
リポジトリ

[ を使用して接続するOAuth] または [Bitbucket アプリパスワードを使用して接続する] を選択し、手順に従って Bitbucket に接続(または再接続)します。

アカウントのパブリックリポジトリまたはリポジトリを選択します。

ソースバージョン

ブランチ、コミット ID、タグ、または参照とコミット ID を入力します。詳細については、「AWS CodeBuild のソースバージョンのサンプル」を参照してください。

Git のクローンの深さ

[Git のクローンの深さ] を選択して、指定されるコミット数で切り捨てられる履歴の浅いクローンを作成します。完全クローンを希望する場合には、[Full (完全)] を選択します。

Git サブモジュールを使用する

リポジトリに Git サブモジュールを含める場合を選択します。

ビルドの開始と完了のステータスをソースプロバイダーに報告する場合は、[ビルドの開始と終了時に、ビルドのステータスをソースプロバイダーにレポートする] を選択します。

注記

ウェブフックによってトリガーされたビルドのステータスは常にソースプロバイダーにレポートされます。

でコードの変更がこのリポジトリにプッシュされるたびにソースコードをビルドする場合は、[Rebuild every time a code change is pushed to this repository (コードの変更がこのリポジトリにプッシュされるたびに再構築する)] を選択します。CodeBuildウェブフックは、独自の Bitbucket、GitHub、または GitHub Enterprise リポジトリでのみ許可されます。

[Status context (ステータスコンテキスト)] に、Bitbucket コミットステータスの name パラメータに使用する値を入力します。詳細については、Bitbucket API ドキュメントの「build」を参照してください。

[ターゲット URL] に、Bitbucket コミットステータスの url パラメータに使用する値を入力します。詳細については、Bitbucket API ドキュメントの「build」を参照してください。

[イベントタイプ] で [コードの変更がこのリポジトリにプッシュされるたびに再構築する] を選択した場合は、ビルドをトリガーするイベントを選択します。フィルタを作成するには正規表現を使用します。フィルタを指定しない場合、プルリクエストのすべての更新および作成と、すべてのプッシュイベントで、ビルドがトリガーされます。詳細については、「GitHubウェブフックイベント」および「Bitbucket ウェブフックイベント」を参照してください。

GitHub
リポジトリ

[ を使用して接続するOAuth] または [ 個人用アクセストークンを使用して接続する] を選択し、GitHub に接続(または再接続)して へのアクセスを許可する手順に従います。GitHubAWS CodeBuild

アカウントのパブリックリポジトリまたはリポジトリを選択します。

ソースバージョン

ブランチ、コミット ID、タグ、または参照とコミット ID を入力します。詳細については、「AWS CodeBuild のソースバージョンのサンプル」を参照してください。

Git のクローンの深さ

[Git のクローンの深さ] を選択して、指定されるコミット数で切り捨てられる履歴の浅いクローンを作成します。完全クローンを希望する場合には、[Full (完全)] を選択します。

Git サブモジュールを使用する

リポジトリに Git サブモジュールを含める場合を選択します。

ビルドの開始と完了のステータスをソースプロバイダーにレポートする場合は、ビルドの開始と終了のステータスをソースプロバイダーにレポートするを選択する。

注記

ウェブフックによってトリガーされたビルドのステータスは常にソースプロバイダーにレポートされます。

でコードの変更がこのリポジトリにプッシュされるたびにソースコードをビルドするには、[Rebuild every time a code change is pushed to this repository (コードの変更がこのリポジトリにプッシュされるたびに再構築する)] を選択します。CodeBuildウェブフックは、独自の Bitbucket、GitHub、または GitHub Enterprise リポジトリでのみ許可されます。

[Status context (ステータスコンテキスト)] に、context コミットステータスの GitHub パラメータに使用される値を入力します。詳細については、 開発者ガイドの「コミットステータスの作成GitHub」を参照してください。

[ターゲット URL] に、target_url コミットステータスの GitHub パラメータに使用する値を入力します。詳細については、 開発者ガイドの「コミットステータスの作成GitHub」を参照してください。

[イベントタイプ] で [コードの変更がこのリポジトリにプッシュされるたびに再構築する] を選択した場合は、ビルドをトリガーするイベントを選択します。フィルタを作成するには正規表現を使用します。フィルタを指定しない場合、プルリクエストのすべての更新および作成と、すべてのプッシュイベントで、ビルドがトリガーされます。詳細については、「GitHubウェブフックイベント」および「Bitbucket ウェブフックイベント」を参照してください。

GitHub Enterprise Server
GitHub エンタープライズ個人用のアクセストークン

個人用アクセストークンをクリップボードにコピーする方法については、「GitHubエンタープライズサーバーのサンプル」を参照してください。テキストフィールドにトークンを貼り付け、[トークンの保存] を選択します。

注記

個人用アクセストークンは、一回のみ入力して保存する必要があります。CodeBuild では、以降のすべてのプロジェクトにこのトークンを使用します。

ソースバージョン

プルリクエスト、ブランチ、コミット ID、タグ、または参照とコミット ID を入力します。詳細については、「AWS CodeBuild のソースバージョンのサンプル」を参照してください。

Git のクローンの深さ

[Git のクローンの深さ] を選択して、指定されるコミット数で切り捨てられる履歴の浅いクローンを作成します。完全クローンを希望する場合には、[Full (完全)] を選択します。

Git サブモジュールを使用する

リポジトリに Git サブモジュールを含める場合を選択します。

ビルドステータス

ビルドの開始と完了のステータスをソースプロバイダーにレポートする場合は、[ビルドの開始と終了時に、ビルドのステータスをソースプロバイダーにレポートする] を選択します。

注記

ウェブフックによってトリガーされたビルドのステータスは常にソースプロバイダーにレポートされます。

安全でない SSL

Enterprise プロジェクトリポジトリに接続するときの SSL 警告を無視することを選択します。GitHub

でコードの変更がこのリポジトリにプッシュされるたびにソースコードをビルドする場合は、[Rebuild every time a code change is pushed to this repository (コードの変更がこのリポジトリにプッシュされるたびに再構築する)] を選択します。CodeBuildウェブフックは、独自の Bitbucket、GitHub、または GitHub Enterprise リポジトリでのみ許可されます。

[Status context (ステータスコンテキスト)] に、context コミットステータスの GitHub パラメータに使用される値を入力します。詳細については、 開発者ガイドの「コミットステータスの作成GitHub」を参照してください。

[ターゲット URL] に、target_url コミットステータスの GitHub パラメータに使用する値を入力します。詳細については、 開発者ガイドの「コミットステータスの作成GitHub」を参照してください。

[イベントタイプ] で [コードの変更がこのリポジトリにプッシュされるたびに再構築する] を選択した場合は、ビルドをトリガーするイベントを選択します。フィルタを作成するには正規表現を使用します。フィルタを指定しない場合、プルリクエストのすべての更新および作成と、すべてのプッシュイベントで、ビルドがトリガーされます。詳細については、「GitHubウェブフックイベント」および「Bitbucket ウェブフックイベント」を参照してください。

Environment

環境イメージ

次のいずれかを行ってください。

  • AWS CodeBuild が管理する Docker イメージを使用するには、[Managed image (マネージドイメージ)] を選択し、次に [オペレーティングシステム]、[ランタイム]、[イメージ]、および [ランタイムバージョン] で適切な選択を行います。利用可能な場合は、[環境タイプ] から選択します。

  • 別の Docker イメージを使用するには、[カスタムイメージ] を選択します。[環境タイプ] は、ARMLinuxLinux GPUWindows を選択します。[Other registry (その他のレジストリ)] を選択した場合は、[External registry URL (外部のレジストリ URL)] に docker repository/docker image name の形式に従って Docker Hub の Docker イメージの名前とタグを入力します。[Amazon ECR] を選択した場合は、[Amazon ECR repository (ECR リポジトリ)] および [Amazon ECR image (ECR イメージ)] を使用して AWS アカウントの Docker イメージを選択します。

  • プライベート Docker イメージを使用するには、[カスタムイメージ] を選択します。[環境タイプ] は、ARMLinuxLinux GPUWindows を選択します。[Image registry (イメージレジストリ)] に [Other registry (その他のレジストリ)] を選択して、その後プライベート Docker イメージの認証情報の ARN を入力します。認証情報は、Secrets Manager で作成する必要があります。詳細については、AWS Secrets Manager ユーザーガイドの「AWS Secrets Manager とは」を参照してください。

Privileged

(オプション) このビルドプロジェクトを使用して Docker イメージを作成し、選択したビルド環境イメージが Docker サポート付きの CodeBuild によって提供されない場合にのみ、[特権付与] を選択します。それ以外の場合、関連付けられているビルドで Docker デーモンと通信しようとすると、すべて失敗します。ビルドが Docker デーモンと連係動作できるように、Docker デーモンも起動する必要があります。これを行う 1 つの方法は、次のビルドコマンドを実行してビルドスペックの install フェーズで Docker デーモンを初期化することです。Docker をサポートする CodeBuild によって提供されるビルド環境イメージを選択した場合は、これらのコマンドを実行しないでください。

注記

By default, Docker containers do not allow access to any devices. Privileged mode grants a build project's Docker container access to all devices. For more information, see Runtime Privilege and Linux Capabilities on the Docker Docs website.

- nohup /usr/local/bin/dockerd --host=unix:///var/run/docker.sock --host=tcp://127.0.0.1:2375 --storage-driver=overlay2 & - timeout -t 15 sh -c "until docker info; do echo .; sleep 1; done"
サービス ロール

次のいずれかを行ってください。

  • CodeBuildサービスロールがない場合は、[New service role (新しいサービスロール)] を選択します。[Role name] に、新しいロールの名前を入力します。

  • CodeBuildサービスロールがある場合は、[既存のサービスロール] を選択します。[Role ARN] (ロール ARN) で、サービスロールを選択します。

注記

コンソールを使用してビルドプロジェクトを作成すると、CodeBuildサービスロールを同時に作成できます。デフォルトでは、ロールはそのビルドプロジェクトでのみ使用できます。コンソールでは、このサービスロールを別のビルドプロジェクトと関連付けると、この別のビルドプロジェクトで使用できるようにロールが更新されます。サービスロールは最大 10 個のビルドプロジェクトで使用できます。

追加設定
タイムアウト

5 分から 480 分 (8 時間) の間の値を指定します。この時間が経過すると、 は完了していない場合にビルドCodeBuildを停止します。[hours] と [minutes] を空白のままにすると、デフォルト値の 60 分が使用されます。

VPC

If you want CodeBuild to work with your VPC:

  • For VPC, choose the VPC ID that CodeBuild uses.

  • For VPC Subnets, choose the subnets that include resources that CodeBuild uses.

  • For VPC Security groups, choose the security groups that CodeBuild uses to allow access to resources in the VPCs.

For more information, see Amazon Virtual Private Cloud で AWS CodeBuild を使用する.

コンピューティング

使用可能なオプションの 1 つを選択します。

環境変数

名前と値を入力し、ビルドで使用する各環境変数のタイプを選択します。

注記

CodeBuild は AWS リージョンの環境変数を自動的に設定します。以下の環境変数を buildspec.yml に追加していない場合は、それらの変数を設定する必要があります。

  • AWS_ACCOUNT_ID

  • IMAGE_REPO_NAME

  • IMAGE_TAG

コンソールと AWS CLI のユーザーは環境変数を表示できます。環境変数の表示に懸念がない場合は、[Name] および [Value] フィールドを設定し、[Type] を [Plaintext] に設定します。

Amazon EC2 Systems Manager パラメータストアまたは AWS Secrets Manager には、AWS アクセスキー ID、AWS シークレットアクセスキー、またはパスワードなどの機密値を持つ環境変数をパラメータとして保存することをお勧めします。

Amazon EC2 Systems Manager パラメータストアを使用する場合は、[Type (タイプ)] で、[Parameter (パラメータ)] を選択します。[名前] に、参照する CodeBuild の識別子を入力します。[] に、Amazon EC2 Systems Manager パラメータストアに保存されているパラメータの名前を入力します。たとえば、/CodeBuild/dockerLoginPassword という名前のパラメータを使用して、[タイプ] で [Parameter (パラメータ)] を選択します。[Name] に「LOGIN_PASSWORD」と入力します。 値には、 と入力します/CodeBuild/dockerLoginPassword

重要

If you use Amazon EC2 Systems Manager Parameter Store, we recommend that you store parameters with parameter names that start with /CodeBuild/ (for example, /CodeBuild/dockerLoginPassword). You can use the CodeBuild console to create a parameter in Amazon EC2 Systems Manager. Choose Create parameter, and then follow the instructions in the dialog box. (In that dialog box, for KMS key, you can specify the ARN of an AWS KMS key in your account. Amazon EC2 Systems Manager uses this key to encrypt the parameter's value during storage and decrypt it during retrieval.) If you use the CodeBuild console to create a parameter, the console starts the parameter name with /CodeBuild/ as it is being stored. For more information, see Systems Manager Parameter Store and Systems Manager Parameter Store Console Walkthrough in the Amazon EC2 Systems Manager User Guide.

If your build project refers to parameters stored in Amazon EC2 Systems Manager Parameter Store, the build project's service role must allow the ssm:GetParameters action. If you chose New service role earlier, CodeBuild includes this action in the default service role for your build project. However, if you chose Existing service role, you must include this action to your service role separately.

If your build project refers to parameters stored in Amazon EC2 Systems Manager Parameter Store with parameter names that do not start with /CodeBuild/, and you chose New service role, you must update that service role to allow access to parameter names that do not start with /CodeBuild/. This is because that service role allows access only to parameter names that start with /CodeBuild/.

If you choose New service role, the service role includes permission to decrypt all parameters under the /CodeBuild/ namespace in the Amazon EC2 Systems Manager Parameter Store.

Environment variables you set replace existing environment variables. For example, if the Docker image already contains an environment variable named MY_VAR with a value of my_value, and you set an environment variable named MY_VAR with a value of other_value, then my_value is replaced by other_value. Similarly, if the Docker image already contains an environment variable named PATH with a value of /usr/local/sbin:/usr/local/bin, and you set an environment variable named PATH with a value of $PATH:/usr/share/ant/bin, then /usr/local/sbin:/usr/local/bin is replaced by the literal value $PATH:/usr/share/ant/bin.

Do not set any environment variable with a name that begins with CODEBUILD_. This prefix is reserved for internal use.

If an environment variable with the same name is defined in multiple places, the value is determined as follows:

  • The value in the start build operation call takes highest precedence.

  • The value in the build project definition takes next precedence.

  • The value in the buildspec declaration takes lowest precedence.

Secrets Manager を使用する場合は、[Type (タイプ)] で、[Secrets Manager (シークレットマネージャー)] を選択します。[名前] に、参照する CodeBuild の識別子を入力します。[Value] に、パターン reference-key を使用して を入力しますsecret-id:json-key:version-stage:version-id。 詳細については、「」を参照してくださいSecrets Manager reference-key in the buildspec file

重要

If you use Secrets Manager, we recommend that you store secrets with names that start with /CodeBuild/ (for example, /CodeBuild/dockerLoginPassword). For more information, see What Is AWS Secrets Manager? in the AWS Secrets Manager User Guide.

If your build project refers to secrets stored in Secrets Manager, the build project's service role must allow the secretsmanager:GetSecretValue action. If you chose New service role earlier, CodeBuild includes this action in the default service role for your build project. However, if you chose Existing service role, you must include this action to your service role separately.

If your build project refers to secrets stored in Secrets Manager with secret names that do not start with /CodeBuild/, and you chose New service role, you must update the service role to allow access to secret names that do not start with /CodeBuild/. This is because the service role allows access only to secret names that start with /CodeBuild/.

If you choose New service role, the service role includes permission to decrypt all secrets under the /CodeBuild/ namespace in the Secrets Manager.

Buildspec

ビルド仕様

次のいずれかを行ってください。

  • ソースコードにビルド仕様ファイルが含まれている場合は、[Use a buildspec file (buildspec ファイルを使用)] を選択します。デフォルトでは、CodeBuild はソースコードのルートディレクトリで buildspec.yml という名前のファイルを探します。buildspec ファイルに別の名前または場所が使用されている場合は、Buildspec 名のソースルートからのパスを入力します ( buildspec-two.ymlconfiguration/buildspec.yml など)。 buildspec ファイルが S3 バケットにある場合は、ビルドプロジェクトと同じAWSリージョンにある必要があります。ARN を使用して buildspec ファイルを指定します(例: arn:aws:s3:::my-codebuild-sample2/buildspec.yml)。

  • ソースコードにビルド仕様ファイルが含まれていない場合、または、ソースコードのルートディレクトリで build ファイルの buildspec.yml フェーズに指定されているものと異なるビルドコマンドを実行する場合は、[ビルドコマンドの挿入] を選択します。[ビルドコマンド] に、build フェーズで実行するコマンドを入力します。複数のコマンドについては、&& で各コマンドを区切ります (mvn test && mvn package など)。他のフェーズでコマンドを実行する場合、または build フェーズのコマンドの長いリストがある場合は、ソースコマンドのルートディレクトリに buildspec.yml ファイルを追加し、ファイルにコマンドを追加してから、[ソースコードのルートディレクトリの buildspec.yml を使用] を選択します。

詳細については、ビルド仕様 (buildspec) に関するリファレンス を参照してください。

バッチ設定

1 つのオペレーションとして、ビルドのグループを実行できます。詳細については、でのバッチビルドAWS CodeBuild を参照してください。

バッチ設定の定義

このプロジェクトでバッチビルドを許可する場合は選択します。

バッチサービスロール

バッチビルドのサービスロールを提供します。

次のいずれかを選択します。

  • バッチサービスロールがない場合は、[New service role (新しいサービスロール)] を選択します。[サービスロール] に、新しいロールの名前を入力します。

  • バッチサービスロールがある場合は、[既存のサービスロール] を選択します。[サービスロール] で、サービスロールを選択します。

バッチビルドでは、バッチ設定に新しいセキュリティロールが導入されます。CodeBuild は、バッチの一部としてビルドを実行するために、ユーザーの代わりに StartBuildStopBuild、および RetryBuild アクションを呼び出すことができる必要があるため、この新しいロールが必要です。お客様は、次の 2 つの理由により、ビルドで使用するロールと同じロールではなく、新しいロールを使用する必要があります。

  • ビルドロール StartBuildStopBuild、および RetryBuild のアクセス許可を与えることで、単一のビルドで buildspec を介してより多くのビルドを開始できます。

  • CodeBuild バッチビルドには、バッチ内のビルドに使用できるビルドタイプとコンピューティングタイプの数に対する制限があります。ビルドロールにこれらのアクセス許可がある場合、ビルド自体がこれらの制限を回避する可能性があります。

バッチで使用できるコンピューティングタイプ

バッチで使用できるコンピューティングタイプを選択します。適用する をすべて選択します。

バッチで使用できるビルドの最大数

バッチで許可されているビルドの最大数を入力します。バッチがこの制限を超えると、バッチは失敗します。

バッチのタイムアウト

バッチビルドが完了するまでの最大時間を入力します。

アーティファクトの結合

バッチのすべてのアーティファクトを 1 つの場所にまとめるには、[Combin all artifacts from batch] を選択します。

Artifacts

タイプ

次のいずれかを行ってください。

  • ビルド出力アーティファクトを作成しない場合は、[No artifacts] を選択します。ビルドテストのみを実行している場合や、Docker イメージを Amazon ECR リポジトリにプッシュする場合には、これを行うことができます。

  • ビルド出力を S3 バケットに保存するには、[Amazon S3] を選択し、以下の操作を行います。

    • ビルド出力 ZIP ファイルまたはフォルダにプロジェクト名を使用する場合は、[Name (名前)] を空白のままにします。それ以外の場合は、名前を入力します。(ZIP ファイルを出力して ZIP ファイルにファイル拡張子を付ける場合は、必ず ZIP ファイル名の後に含めます)。

    • buildspec ファイルで指定した名前で、コンソールで指定した名前を上書きする場合は、[Enable semantic versioning (セマンティックバージョニングを有効にする)] を選択します。buildspec ファイル内の名前は、ビルド時に計算され、Shell コマンド言語を使用します。たとえば、アーティファクト名に日付と時刻を追加して常に一意にできます。アーティファクト名を一意にすると、アーティファクトが上書きされるのを防ぐことができます。詳細については、buildspec の構文 を参照してください。

    • [Bucket name (バケット名)] で、出力バケットの名前を選択します。

    • この手順の前の方で [ビルドコマンドの挿入] を選択した場合は、[出力ファイル] に、ビルド出力 ZIP ファイルまたはフォルダに格納するビルドのファイルの場所を入力します。複数の場所の場合は、各場所をコンマで区切ります (例: appspec.yml, target/my-app.jar)。詳細については、「buildspec の構文」で files の説明を参照してください。

    • ビルドアーティファクトを暗号化しない場合は、[アーティファクト暗号化の削除] を選択します。

アーティファクトのセカンダリセットごとに:

  1. [アーティファクト識別子] には、英数字とアンダースコアのみを使用して 128 文字未満の値を入力します。

  2. [アーティファクトの追加] を選択します。

  3. セカンダリアーティファクトを設定するには、前のステップに従います。

  4. [アーティファクトの保存] を選択します。

追加設定
暗号化キー

(オプション) 次のいずれかを実行します。

  • アカウントの Amazon S3 の AWS 管理のカスタマーマネージドキー (CMK) を使用してビルド出力アーティファクトを暗号化するには、[暗号化キー] を空白のままにします。これがデフォルト値です。

  • カスタマー管理の CMK を使用してビルド出力アーティファクトを暗号化するには、[暗号化キー] に CMK の ARN を入力します。arn:aws:kms:region-ID:account-ID:key/key-ID の形式を使用します。

キャッシュタイプ

For Cache type, choose one of the following:

  • If you do not want to use a cache, choose No cache.

  • If you want to use an Amazon S3 cache, choose Amazon S3, and then do the following:

    • For Bucket, choose the name of the S3 bucket where the cache is stored.

    • (Optional) For Cache path prefix, enter an Amazon S3 path prefix. The Cache path prefix value is similar to a directory name. It makes it possible for you to store the cache under the same directory in a bucket.

      重要

      Do not append a trailing slash (/) to the end of the path prefix.

  • If you want to use a local cache, choose Local, and then choose one or more local cache modes.

    注記

    Docker layer cache mode is available for Linux only. If you choose it, your project must run in privileged mode. The ARM_CONTAINER and LINUX_GPU_CONTAINER environment types and the BUILD_GENERAL1_2XLARGE compute type do not support the use of a local cache.

Using a cache saves considerable build time because reusable pieces of the build environment are stored in the cache and used across builds. For information about specifying a cache in the buildspec file, see buildspec の構文. For more information about caching, see AWS CodeBuild でのキャッシュのビルド.

Logs

作成するログを選択します。Amazon CloudWatch Logs、Amazon S3 ログ、またはその両方を作成できます。

CloudWatch

必要に応じて Amazon CloudWatch Logs logs:

CloudWatch logs

[CloudWatch ログ] を選択します。

グループ名

Amazon CloudWatch Logsロググループの名前を入力します。

ストリーム名

Amazon CloudWatch Logsログストリーム名を入力します。

S3

必要に応じて Amazon S3 logs:

S3 ログ

[S3 logs (S3 ログ)] を選択します。

バケット

ログ用の S3 バケットの名前を選択します。

パスプレフィックス

ログのプレフィックスを入力します。

S3 ログの暗号化を無効にする

S3 ログを暗号化しない場合に選択します。