AWS CodeBuild でのビルドプロジェクトの設定の変更
ビルドプロジェクトの設定を変更するには、AWS CodeBuild コンソール、AWS CLI、または AWS SDK を使用します。
ビルドプロジェクトにテストレポートを追加する場合は、テストレポートのアクセス許可 で記載されている権限が IAM ロールに付与されていることを確認してください。
ビルドプロジェクトの設定の変更 (コンソール)
ビルドプロジェクトの設定を変更するには、次の手順を実行します。
AWS CodeBuild コンソール (https://console.aws.amazon.com/codesuite/codebuild/home
) を開きます。 -
ナビゲーションペインで、[Build projects] を選択します。
-
次のいずれかを行ってください。
-
変更するビルドプロジェクトのリンクを選択し、[ビルドの詳細] を選択します。
-
変更するビルドプロジェクトの横にあるラジオボタンを選択して、[View details (詳細を表示)] を選択後 [ビルドの詳細] を選択します。
-
次のセクションを変更できます。
プロジェクトの設定
[プロジェクトの設定] セクションで、[編集] を選択します。変更が完了したら、[設定の更新] を選択して新しい設定を保存します。
次のプロパティを変更できます。
- 説明
-
また、他のユーザーがこのプロジェクトの使用目的を理解できるように、ビルドプロジェクトの説明を任意で指定することもできます。
- ビルドバッジ
-
[Enable build badge (ビルドバッジを有効にする)] を選択すると、プロジェクトのビルドステータスが表示可能および埋め込み可能になります。詳細については、「ビルドバッジサンプル」を参照してください。
注記
ソースプロバイダーが Amazon S3 の場合、ビルドバッジは適用されません。
- 同時ビルド制限を有効にする
-
このプロジェクトで同時ビルド数を制限するには、次の手順を実行します。
-
[Restrict number of concurrent builds this project can start] (このジョブで許可される同時実行の最大数を設定) を選択します。
-
[Concurrent build limit] (同時ビルド制限) で、このジョブで許可される同時実行の最大数を設定します。この制限は、アカウントに設定された同時ビルド制限より大きくすることはできません。アカウント制限を超える数値を入力しようとすると、エラーメッセージが表示されます。
新しいビルドは、現在のビルド数がこの制限以下の場合にのみ開始されます。現在のビルドカウントがこの制限を満たす場合、新しいビルドはスロットルされ、実行されません。
-
- パブリックビルドアクセスを有効にする
-
AWS アカウントにアクセスできないユーザーを含めて、プロジェクトのビルド結果を一般に公開するには、[Enable public build access] (パブリックビルドアクセスを有効にする) を選択し、ビルド結果を公開することを確定します。パブリックビルドプロジェクトでは、次のプロパティが使用されます。
- パブリックビルドのサービスロール
-
CodeBuild で新しいサービスロールを作成する場合は [New service role] (新しいサービスロール) を、既存のサービスロールを使用する場合は [Existing service role] (既存のサービスロール) を選択します。
パブリックビルドのサービスロールを使用することにより、CodeBuild で CloudWatch Logs を読み取り、プロジェクトのビルド用の Amazon S3 アーティファクトをダウンロードできます。これは、プロジェクトのビルドログとアーティファクトを一般に公開するために必要です。
- サービスロール
-
新しいサービスロールまたは既存のサービスロールの名前を入力します。
プロジェクトのビルド結果をプライベートにするには、[Enable public build access] (パブリックビルドアクセスを有効にする) のチェックを外します。
詳細については、「パブリックビルドプロジェクトの URL を取得」を参照してください。
警告
プロジェクトのビルド結果を一般に公開する際には、以下に留意してください。
-
プロジェクトがプライベートだったときに実行されたビルドも含めて、プロジェクトのビルド結果、ログ、アーティファクトはすべて、一般に公開されます。
-
すべてのビルドログとアーティファクトが一般に公開されます。環境変数、ソースコード、およびその他の機密情報がビルドログとアーティファクトに出力されている可能性があります。ビルドログに出力される情報には注意が必要です。以下にベストプラクティスを示します。
-
機密値、特に AWS アクセスキー ID やシークレットアクセスキーを格納する場合には、環境変数を使用しないようにします。Amazon EC2 Systems Manager パラメータストアまたは AWS Secrets Manager を使用して機密値を格納することをお勧めします。
-
ウェブフック使用のベストプラクティス。 に従って、ビルドをトリガーできるエンティティを制限し、buildspec をプロジェクト自体に保存しないことで、Webhook を可能な限り安全に保つことができます。
-
-
悪意のあるユーザーがパブリックビルドを利用して、悪意のあるアーティファクトを配信する可能性があります。プロジェクト管理者は、すべてのプルリクエストを確認し、プルリクエストが正当な変更であるか検証することをお勧めします。また、チェックサムを使ってすべてのアーティファクトを検証し、正しいアーティファクトがダウンロードされているか確認することを推奨します。
- 追加情報
-
[タグ] に、サポート対象の AWS のサービスで使用するタグの名前と値を入力します。[Add row] を使用して、タグを追加します。最大 50 個のタグを追加できます。
ソース
[ソース] セクションで [編集] を選択します。変更が完了したら、[設定の更新] を選択して新しい設定を保存します。
次のプロパティを変更できます。
- ソースプロバイダー
-
ソースコードプロバイダーのタイプを選択します。次のリストを使用して、ソースプロバイダーに関する適切な選択を行います。
注記
CodeBuild は Bitbucket サーバーをサポートしていません。
環境
[環境] セクションで、[編集] を選択します。変更が完了したら、[設定の更新] を選択して新しい設定を保存します。
次のプロパティを変更できます。
- [プロビジョニングモデル]
-
プロビジョニングモデルを変更するには、[プロビジョニングモデルを変更] を選択し、次のいずれかを実行します。
-
AWS CodeBuild が管理するオンデマンドフリートを使用するには、[オンデマンド] を選択します。オンデマンドフリートでは、CodeBuild がビルドのコンピューティングを行います。マシンはビルドが終了すると破棄されます。オンデマンドフリートはフルマネージド型で、需要の急増にも対応できる自動スケーリング機能を備えています。
-
AWS CodeBuild が管理するリザーブドキャパシティフリートを使用するには、[リザーブドキャパシティ] を選択し、[フリート名] を選択します。リザーブドキャパシティフリートでは、ビルド環境に合わせて専有インスタンスのセットを設定します。これらのマシンはアイドル状態のままで、ビルドやテストをすぐに処理できる状態になり、ビルド時間を短縮します。リザーブドキャパシティフリートでは、マシンは常に稼働しており、プロビジョニングされている間はコストが発生し続けます。
詳細については、リザーブドキャパシティキャパシティフリートでビルドを実行 を参照してください。
-
- 環境イメージ
-
ビルドイメージを変更するには、[イメージの上書き] を選択し、次のいずれかを実行します。
-
が管理する Docker イメージを使用するにはAWS CodeBuild、[Managed image (マネージドイメージ)] を選択し、次に [オペレーティングシステム]、[ランタイム]、[イメージ]、および [ランタイムバージョン] で適切な選択を行います。利用可能な場合は、[環境タイプ] から選択します。
-
別の Docker イメージを使用するには、[カスタムイメージ] を選択します。[Environment type (環境タイプ)] で、 [ARM]、[Linux]、[Linux GPU] または [Windows] を選択します。[Other registry (その他のレジストリ)] を選択した場合は、[External registry URL (外部のレジストリ URL)] に
docker repository/docker image name -
プライベート Docker イメージを使用するには、[カスタムイメージ] を選択します。[Environment type (環境タイプ)] で、 [ARM]、[Linux]、[Linux GPU] または [Windows] を選択します。[Image registry (イメージレジストリ)] に [Other registry (その他のレジストリ)] を選択して、その後プライベート Docker イメージの認証情報の ARN を入力します。認証情報は、Secrets Manager で作成する必要があります。詳細については、AWS Secrets Managerユーザーガイドの「AWS Secrets Manager とは」を参照してください。
注記
CodeBuild はカスタムDocker イメージの「
ENTRYPOINT」をオーバーライドします。 -
- サービスロール
次のいずれかを行ってください。
-
CodeBuild サービスロールがない場合は、[新しいサービスロール] を選択します。[Role name] に、新しいロールの名前を入力します。
-
CodeBuild サービスロールがある場合は、[Existing service role (既存のサービスロール)] を選択します。[Role ARN] で、サービスロールを選択します。
注記
コンソールでは、ビルドプロジェクトの作成時に CodeBuild サービスロールも作成できます。デフォルトでは、ロールはそのビルドプロジェクトでのみ使用できます。コンソールでは、このサービスロールを別のビルドプロジェクトと関連付けると、この別のビルドプロジェクトで使用できるようにロールが更新されます。サービスロールは最大 10 個のビルドプロジェクトで使用できます。
-
- 追加設定
-
- タイムアウト
-
5 分～36 時間の間の値を指定します。この時間が経過してもビルドが完了していない場合、CodeBuild はビルドを停止します。[hours] と [minutes] を空白のままにすると、デフォルト値の 60 分が使用されます。
- 特権付与
-
[Docker イメージをビルドする場合、またはビルドで昇格された権限を取得する場合は、このフラグを有効にする] を選択します。それ以外の場合、関連付けられているビルドで Docker デーモンと通信しようとすると、すべて失敗します。ビルドが Docker デーモンと連係動作できるように、Docker デーモンも起動する必要があります。これを行う 1 つの方法は、次のビルドコマンドを実行してビルドスペックの
installフェーズで Docker デーモンを初期化することです。Docker をサポートする CodeBuild によって提供されるビルド環境イメージを選択した場合は、これらのコマンドを実行しないでください。注記
デフォルトでは、Docker デーモンは非 VPC ビルドで有効になっています。VPC ビルドに Docker コンテナを使用する場合は、Docker Docs ウェブサイトの「Runtime Privilege and Linux Capabilities
」を参照して、特権モードを有効にします。また、Windows は特権モードをサポートしていません。 - nohup /usr/local/bin/dockerd --host=unix:///var/run/docker.sock --host=tcp://127.0.0.1:2375 --storage-driver=overlay2 & - timeout 15 sh -c "until docker info; do echo .; sleep 1; done" - VPC
CodeBuild を VPC と連携させたい場合
-
[VPC] で、CodeBuild が使用する VPC ID を選択します。
-
[VPC Subnets (サブネット)] で、CodeBuild が使用するリソースを含むサブネットを選択します。
-
[VPC Security groups (VPC セキュリティグループ)] で、CodeBuild が VPC 内のリソースへのアクセスを許可するために使用するセキュリティグループを選択します。
詳細については、「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 (パラメータ)] を選択します。[Name] (名前) に、参照する CodeBuild の識別子を入力します。[Value] (値) に、Amazon EC2 Systems Manager パラメータストアに保存されているパラメータの名前を入力します。たとえば、
/CodeBuild/dockerLoginPasswordという名前のパラメータを使用して、[タイプ] で [Parameter (パラメータ)] を選択します。[Name (名前)] にLOGIN_PASSWORDと入力します。[Value (値)] に「/CodeBuild/dockerLoginPassword」と入力します。重要
Amazon EC2 Systems Manager パラメータストアを使用する場合、パラメータは
/CodeBuild/で始まるパラメータ名（例:/CodeBuild/dockerLoginPassword）で保存することをお勧めします。CodeBuild コンソールを使用して、Amazon EC2 Systems Manager にパラメータを作成することができます。[パラメータの作成] を選択し、ダイアログボックスの手順に従います。(ダイアログボックスでは、[KMS キー] の場合、アカウントの AWS KMS キーの ARN を指定できます。Amazon EC2 Systems Manager では、このキーを使用して、保存中にパラメータの値を暗号化し、取得中に復号化します)。CodeBuild コンソールを使用してパラメータを作成した場合、コンソールは保存されている/CodeBuild/パラメータ名を開始します。詳細については、Amazon EC2 Systems Manager ユーザーガイドの「Systems Manager パラメータストア」および「Systems Manager パラメータストアコンソールのチュートリアル」を参照してください。ビルドプロジェクトが Amazon EC2 Systems Manager パラメータストアに保存されているパラメータを参照する場合、ビルドプロジェクトのサービスロールで
ssm:GetParametersアクションを許可する必要があります。以前に [New service role] (新しいサービスロール) を選択した場合は、CodeBuild のビルドプロジェクトのデフォルトのサービスロールにこのアクションが含まれています。ただし [既存のサービスロール] を選択した場合は、このアクションをサービスロールに個別に含める必要があります。ビルドプロジェクトが、
/CodeBuild/で始まらないパラメータ名を持つ、Amazon EC2 Systems Manager パラメータストアに保存されているパラメータを参照し、[新しいサービスロール] を選択した場合、/CodeBuild/で始まらないパラメータ名にアクセスできるようにサービスロールを更新する必要があります。これは、サービスロールで、/CodeBuild/で始まるパラメータ名にのみアクセスが許可されるためです。[新しいサービスロールを作成] を選択した場合、サービスロールには、Amazon EC2 Systems Manager パラメータストアの
/CodeBuild/名前空間ですべてのパラメータを復号するアクセス権限が含まれます。既存の環境変数は、設定した環境変数により置き換えられます。たとえば、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_で始まる名前の環境変数は設定しないでください。このプレフィックスは内部使用のために予約されています。同じ名前の環境変数が複数の場所で定義されている場合は、その値は次のように決定されます。
-
ビルド開始オペレーション呼び出しの値が最も優先順位が高くなります。
-
ビルドプロジェクト定義の値が次に優先されます。
-
ビルド仕様宣言の値の優先順位が最も低くなります。
Secrets Manager を使用する場合は、[Type] (タイプ) で、[Secrets Manager] を選択します。[Name] (名前) に、参照する CodeBuild の識別子を入力します。[Value (値)] に、パターン
reference-keyを使用してsecret-id:json-key:version-stage:version-id重要
Secrets Manager を使用する場合は、「
/CodeBuild/」で始まる名前でシークレットを保存することをお勧めします(たとえば、/CodeBuild/dockerLoginPassword)。詳細については、AWS Secrets Managerユーザーガイドの「AWS Secrets Manager とは」を参照してください。ビルドプロジェクトが Secrets Manager パラメータストアに保存されているパラメータを参照する場合、ビルドプロジェクトのサービスロールで
secretsmanager:GetSecretValueアクションを許可する必要があります。以前に [New service role] (新しいサービスロール) を選択した場合は、CodeBuild のビルドプロジェクトのデフォルトのサービスロールにこのアクションが含まれています。ただし [既存のサービスロール] を選択した場合は、このアクションをサービスロールに個別に含める必要があります。ビルドプロジェクトが、
/CodeBuild/で始まらないパラメータ名を持つ、Secrets Manager に保存されているパラメータを参照し、[新しいサービスロール] を選択した場合、/CodeBuild/で始まらないシークレット名にアクセスできるようにサービスロールを更新する必要があります。これは、サービスロールで、/CodeBuild/で始まるシークレット名にのみアクセスが許可されるためです。[新しいサービスロール] を選択した場合、作成されるサービスロールには、Secrets Manager の
/CodeBuild/名前空間ですべてのシークレットを復号するアクセス許可が含まれます。 -
Buildspec
[Buildspec] セクションで、[編集] を選択します。変更が完了したら、[設定の更新] を選択して新しい設定を保存します。
次のプロパティを変更できます。
- ビルド仕様
-
次のいずれかを行ってください。
-
ソースコードにビルド仕様ファイルが含まれている場合は、[Use a buildspec file (buildspec ファイルを使用)] を選択します。デフォルトでは、CodeBuild はソースコードのルートディレクトリで
buildspec.ymlという名前のファイルを探します。buildspec ファイルに別の名前または場所が使用されている場合は、Buildspec 名 にソースルートからのパスを入力します (例えば、buildspec-two.ymlまたはconfiguration/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ファイルを追加し、ファイルにコマンドを追加してから、[Use the buildspec.yml in the source code root directory] (ソースコードのルートディレクトリの 「buildspec.yml」を使用) を選択します。
詳細については、「ビルド仕様 (buildspec) に関するリファレンス」を参照してください。
-
Batch 構成
[バッチ構成] セクションで、[編集] を選択します。変更が完了したら、[設定の更新] を選択して新しい設定を保存します。詳細については、「ビルドをバッチで実行」を参照してください。
次のプロパティを変更できます。
- Batch サービスロール
-
バッチビルドのサービスロールを提供します。
次のいずれかを選択します。
-
バッチサービスロールがない場合は、[New service role] (新しいサービスロール) を選択します。[Service role] (サービスロール) に、新しいロールの名前を入力します。
-
バッチサービスロールがある場合は、[Existing service role] (既存のサービスロール) を選択します。[Service role] (サービスロール) で、サービスロールを選択します。
バッチビルドでは、バッチ設定に新しいセキュリティロールが導入されます。この新しいロールでは、CodeBuild が
StartBuild、StopBuildおよびRetryBuildアクションを使用して、バッチの一部としてビルドを実行する上で必要です。次の2つの理由により、お客様はビルドで使用するものと同じロールではなく、新しいロールを使用する必要があります。-
ビルドの役割を与える
StartBuild、StopBuild、およびRetryBuildアクセス権限を使用すると、単一のビルドが buildspec を介してより多くのビルドを開始することができます。 -
CodeBuild バッチビルドには、バッチ内のビルドに使用できるビルドと計算タイプの数を制限する制限があります。ビルドロールにこれらの権限がある場合、ビルド自体がこれらの制限を回避する可能性があります。
-
- バッチに使用できる計算タイプ
-
バッチに使用できる計算タイプを選択します。該当するものをすべて選択します。
- バッチで許可される最大ビルド
-
バッチで許可されるビルドの最大数を入力します。バッチがこの制限を超えると、バッチは失敗します。
- バッチのタイムアウト
-
バッチビルドが完了する最大時間を入力します。
- アーティファクトの結合
-
[Combine all artifacts from batch into a single location] (バッチのすべてのアーチファクト) を 1 つの場所に結合するを選択して、バッチのすべてのアーチファクトを単一の場所に結合します。
- バッチレポートモード
-
バッチビルドに対して望ましいビルドステータスレポートモードを選択します。
注記
このフィールドが利用可能になるのは、プロジェクトソースが Bitbucket、GitHub、または GitHub Enterprise であり、[Source] (ソース) で [Report build statuses to source provider when your builds start and finish] (ビルドの開始と終了時にソースプロバイダーにビルドステータスをレポートする) が選択されている場合のみです。
- 集約されたビルド
-
これを選択して、バッチ内にあるすべてのビルドのステータスを単一のステータスレポートにまとめます。
- 個々のビルド
-
これを選択して、バッチ内にあるすべてのビルドのビルドステータスが個別に報告されるようにします。
アーティファクト
[アーティファクト] セクションで、[編集] を選択します。変更が完了したら、[設定の更新] を選択して新しい設定を保存します。
次のプロパティを変更できます。
- タイプ
-
次のいずれかを行ってください。
-
ビルド出力アーティファクトを作成しない場合は、[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)。詳細については、「files」で buildspec の構文 の説明を参照してください。 -
ビルドアーティファクトを暗号化しない場合は、[アーティファクト暗号化の削除] を選択します。
-
アーティファクトのセカンダリセットごとに:
-
[Artifact 識別子] には、英数字とアンダースコアのみを使用して 128 文字未満の値を入力します。
-
[アーティファクトの追加] を選択します。
-
セカンダリアーティファクトを設定するには、前のステップに従います。
-
[アーティファクトの保存] を選択します。
-
- 追加設定
-
- 暗号化キー
-
次のいずれかを行います。
-
アカウントの AWS マネージドキー Amazon S3 を使用して、ビルド出力アーティファクトを暗号化するには、[暗号化キー] を空白のままにします。これがデフォルトです。
-
カスタマー管理のキーを使用してビルド出力アーティファクトを暗号化するには、[暗号化キー] にカスタマー管理のキーの ARN を入力します。
arn:aws:kms:の形式を使用します。region-ID:account-ID:key/key-ID
-
- キャッシュタイプ
[キャッシュタイプ] で、以下のいずれかを選択します。
-
キャッシュを使用しない場合は、[No cache] を選択します。
-
Amazon S3 キャッシュを使用するには、[Amazon S3] を選択して次の操作を行います。
-
[バケット] では、キャッシュが保存される S3 バケットの名前を選択します。
-
(オプション) [Cache path prefix (キャッシュパスのプレフィックス)] に、Amazon S3 パスのプレフィックスを入力します。[キャッシュパスのプレフィックス] 値はディレクトリ名に似ています。これにより、バケット内の同じディレクトリにキャッシュを保存できます。
重要
パスのプレフィックスの末尾にスラッシュ (/) を付加しないでください。
-
-
ローカルキャッシュを使用する場合は、[ローカル] を選択し、ローカルキャッシュモードを 1 つ以上選択します。
注記
Docker レイヤーキャッシュモードは Linux でのみ利用可能です。このモードを選択する場合、プロジェクトは権限モードで実行する必要があります。
キャッシュを使用すると、再利用可能なビルド環境がキャッシュに保存され、ビルド全体で使用されるため、かなりのビルド時間が節約されます。ビルド仕様ファイルのキャッシュの指定に関する詳細については、「buildspec の構文」を参照してください。キャッシングの詳細については、「パフォーマンスを向上させるためのキャッシュビルド」を参照してください。
-
ログ
[ログ] セクションで [編集] を選択します。変更が完了したら、[設定の更新] を選択して新しい設定を保存します。
次のプロパティを変更できます。
作成するログを選択します。Amazon CloudWatch Logs、Amazon S3 ログ、または両方のログを作成できます。
- CloudWatch
-
Amazon CloudWatch Logs が必要な場合:
- CloudWatch Logs
-
[CloudWatch logs] を選択します。
- グループ名
-
Amazon CloudWatch Logs のログのグループ名を入力します。
- ストリーム名
-
Amazon CloudWatch Logs ログストリーム名を入力します。
- S3
-
Amazon S3 ログが必要な場合は、以下のようになります。
- S3 ログ
-
[S3 logs (S3 ログ)] を選択します。
- バケット
-
ログを保存する S3 バケットの名前を選択します。
- パスプレフィックス
-
ログのプレフィックスを入力します。
- S3 ログの暗号化を無効にする
-
S3 ログを暗号化しない場合は、選択します。
ビルドプロジェクトの設定の変更 (AWS CLI)
AWS CLI を AWS CodeBuild と組み合わせて使用する方法については、「コマンドラインリファレンス」を参照してください。
AWS CLI で CodeBuild プロジェクトを更新するには、更新されたプロパティを含む JSON ファイルを作成し、そのファイルを「update-project」コマンドに渡します。更新ファイルに含まれていないプロパティは変更されません。
更新 JSON ファイルでは、name プロパティおよび変更されたプロパティのみが必要です。name プロパティにより、変更するプロジェクトを識別します。変更された構造については、それらの構造に必要なパラメータも含める必要があります。たとえば、プロジェクトの環境を変更するには、「environment/type」および「environment/computeType」プロパティが必要です。環境イメージを更新する例を次に示します。
{ "name": "<project-name>", "environment": { "type": "LINUX_CONTAINER", "computeType": "BUILD_GENERAL1_SMALL", "image": "aws/codebuild/amazonlinux2-x86_64-standard:4.0" } }
プロジェクトの現在のプロパティ値を取得する必要がある場合は、batch-get-projects コマンドを使用して、変更するプロジェクトの現在のプロパティを取得し、出力をファイルに書き込みます。
aws codebuild batch-get-projects --names "<project-name>" >project-info.json
project-info.json ファイルには、プロジェクトの配列が含まれているため、プロジェクトを更新するために直接使用することはできません。ただし、変更したいプロパティを project-info.json ファイルからコピーして更新ファイル内に貼り付け、変更するプロパティのベースラインとすることができます。詳細については、「ビルドプロジェクトの詳細を表示する (AWS CLI)」を参照してください。
「ビルドプロジェクトの作成 (AWS CLI)」の説明に従って、更新 JSON ファイルを変更し、結果を保存します。更新 JSON ファイルの変更が完了したら、update-project コマンドを実行し、更新 JSON ファイルを渡します。
aws codebuild update-project --cli-input-json file://<update-project-file>
成功した場合、更新されたプロジェクトの JSON が出力に表示されます。必要なパラメータが欠落している場合は、欠落しているパラメータを識別するエラーメッセージが出力に表示されます。たとえば、このエラーメッセージは、「environment/type」パラメータが無いエラーです。
aws codebuild update-project --cli-input-json file://update-project.json Parameter validation failed: Missing required parameter in environment: "type"
ビルドプロジェクトの設定の変更 (AWS SDK)
AWS CodeBuild を AWS SDK と組み合わせて使用する方法については、「AWS SDK とツールのリファレンス」を参照してください。
