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

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

AWS CodeBuild コンソール (https://console.aws.amazon.com/codesuite/codebuild/home) を開きます。

CodeBuild の情報ページが表示された場合、ビルドプロジェクトを作成するを選択します。それ以外の場合は、ナビゲーションペインでビルドを展開し、[ビルドプロジェクト] を選択し、次に [Create build project (ビルドプロジェクトの作成)] を選択します。

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

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

プロジェクトの設定

[Project name] (プロジェクト名)

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

説明

また、他のユーザーがこのプロジェクトの使用目的を理解できるように、ビルドプロジェクトの説明を任意で指定することもできます。

ビルドバッジ

(オプション)[Enable build badge] (ビルドバッジを有効にする) を選択すると、プロジェクトのビルドステータスが表示可能および埋め込み可能になります。詳細については、「ビルドバッジサンプル」を参照してください。

注記

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

同時ビルド制限を有効にする

(オプション) このプロジェクトで同時ビルド数を制限するには、次の手順を実行します。

  1. [Restrict number of concurrent builds this project can start] (このジョブで許可される同時実行の最大数を設定) を選択します。

  2. [Concurrent build limit] (同時ビルド制限) で、このジョブで許可される同時実行の最大数を設定します。この制限は、アカウントに設定された同時ビルド制限より大きくすることはできません。アカウント制限を超える数値を入力しようとすると、エラーメッセージが表示されます。

新しいビルドは、現在のビルド数がこの制限以下の場合にのみ開始されます。現在のビルドカウントがこの制限を満たす場合、新しいビルドはスロットルされ、実行されません。

追加情報

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

ソース

ソースプロバイダー

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

注記

CodeBuild は Bitbucket サーバーをサポートしていません。

Amazon S3
バケット

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

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

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

ソースバージョン

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

CodeCommit
リポジトリ

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

参照タイプ

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

注記

811dd1ba1aba14473856cee38308caed7190c0d または 5392f7 のように、コミット ID と似ていない Git ブランチ名を選択することをお勧めします。これにより、Git checkout が実際のコミットと衝突するのを防ぐことができます。

Git クローンの深度

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

Git サブモジュール

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

Bitbucket
リポジトリ

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

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

ソースバージョン

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

注記

811dd1ba1aba14473856cee38308caed7190c0d または 5392f7 のように、コミット ID と似ていない Git ブランチ名を選択することをお勧めします。これにより、Git checkout が実際のコミットと衝突するのを防ぐことができます。

Git クローンの深度

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

Git サブモジュール

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

ビルドステータス

ビルドの開始と終了のステータスをソースプロバイダーにレポートする場合は、[Report build statuses to source provider when your builds start and finish] (ビルドの開始と終了時にソースプロバイダーにビルドステータスをレポートする) を選択します。

ソースプロバイダにビルド状態を報告できるようにするには、ソースプロバイダに関連付けられたユーザーがリポジトリへの書き込みアクセス権を持っている必要があります。ユーザーが書き込みアクセス権を持っていない場合、ビルドのステータスは更新できません。詳細については、「ソースプロバイダーのアクセス」を参照してください。

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

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

webhook によってトリガーされたビルドのステータスは常にソースプロバイダーにレポートされます。コンソールから開始されたビルドのステータスまたはソースプロバイダーに報告された API 呼び出しを取得するには、この設定を選択する必要があります。

プロジェクトのビルドが webhook によってトリガーされた場合、この設定への変更を有効にするには、新しいコミットをリポジトリにプッシュする必要があります。

[Primary source webhook events] (プライマリソース Webhook イベント) で [Rebuild every time a code change is pushed to this repository] (コード変更がこのリポジトリにプッシュされるたび再構築) を選択して、コード変更がこのリポジトリにプッシュされるたびに CodeBuild で再構築します。Webhook およびフィルターグループの詳細については、「Bitbucket ウェブフックイベント」を参照してください。

GitHub
リポジトリ

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

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

ソースバージョン

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

注記

811dd1ba1aba14473856cee38308caed7190c0d または 5392f7 のように、コミット ID と似ていない Git ブランチ名を選択することをお勧めします。これにより、Git checkout が実際のコミットと衝突するのを防ぐことができます。

Git クローンの深度

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

Git サブモジュール

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

ビルドステータス

ビルドの開始と終了のステータスをソースプロバイダーにレポートする場合は、[Report build statuses to source provider when your builds start and finish] (ビルドの開始と終了時にソースプロバイダーにビルドステータスをレポートする) を選択します。

ソースプロバイダにビルド状態を報告できるようにするには、ソースプロバイダに関連付けられたユーザーがリポジトリへの書き込みアクセス権を持っている必要があります。ユーザーが書き込みアクセス権を持っていない場合、ビルドのステータスは更新できません。詳細については、「ソースプロバイダーのアクセス」を参照してください。

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

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

webhook によってトリガーされたビルドのステータスは、常にソースプロバイダーにレポートされます。コンソールから開始されたビルドのステータスまたはソースプロバイダーに報告された API 呼び出しを取得するには、この設定を選択する必要があります。

プロジェクトのビルドが webhook によってトリガーされた場合、この設定への変更を有効にするには、新しいコミットをリポジトリにプッシュする必要があります。

[Primary source webhook events] (プライマリソース Webhook イベント) で [Rebuild every time a code change is pushed to this repository] (コード変更がこのリポジトリにプッシュされるたび再構築) を選択して、コード変更がこのリポジトリにプッシュされるたびに CodeBuild で再構築します。Webhook およびフィルターグループの詳細については、「GitHub ウェブフックイベント」を参照してください。

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

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

注記

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

ソースバージョン

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

注記

811dd1ba1aba14473856cee38308caed7190c0d または 5392f7 のように、コミット ID と似ていない Git ブランチ名を選択することをお勧めします。これにより、Git checkout が実際のコミットと衝突するのを防ぐことができます。

Git クローンの深度

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

Git サブモジュール

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

ビルドステータス

ビルドの開始と終了のステータスをソースプロバイダーにレポートする場合は、[Report build statuses to source provider when your builds start and finish] (ビルドの開始と終了時にソースプロバイダーにビルドステータスをレポートする) を選択します。

ソースプロバイダにビルド状態を報告できるようにするには、ソースプロバイダに関連付けられたユーザーがリポジトリへの書き込みアクセス権を持っている必要があります。ユーザーが書き込みアクセス権を持っていない場合、ビルドのステータスは更新できません。詳細については、「ソースプロバイダーのアクセス」を参照してください。

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

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

webhook によってトリガーされたビルドのステータスは、常にソースプロバイダーにレポートされます。コンソールから開始されたビルドのステータスまたはソースプロバイダーに報告された API 呼び出しを取得するには、この設定を選択する必要があります。

プロジェクトのビルドが webhook によってトリガーされた場合、この設定への変更を有効にするには、新しいコミットをリポジトリにプッシュする必要があります。

安全でない SSL

[Enable insecure SSL (セキュアでない SSL を有効にする)] を選択して、GitHub Enterprise プロジェクトリポジトリに接続するときの SSL 警告を無視します。

[Primary source webhook events] (プライマリソース Webhook イベント) で [Rebuild every time a code change is pushed to this repository] (コード変更がこのリポジトリにプッシュされるたび再構築) を選択して、コード変更がこのリポジトリにプッシュされるたびに CodeBuild で再構築します。Webhook およびフィルターグループの詳細については、「GitHub ウェブフックイベント」を参照してください。

環境

環境イメージ

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

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

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

  • プライベート 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」をオーバーライドします。

特権付与

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

注記

デフォルトでは、Docker コンテナはどのデバイスにもアクセスできません。権限モードは、ビルドプロジェクトの Docker コンテナにすべてのデバイスへのアクセスを許可します。詳細については、Docker Docs Web サイトの「Runtime Privilege and Linux Capabilities」を参照してください。

- 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"
サービスロール

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

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

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

注記

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

追加設定
タイムアウト

5 分~8 時間の間の値を指定します。この時間が経過すると、CodeBuild が実行中のビルドを停止します。[hours] と [minutes] を空白のままにすると、デフォルト値の 60 分が使用されます。

[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_valueother_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 reference-key in the buildspec fileを参照してください。

重要

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

ビルド仕様

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

  • ソースコードにビルド仕様ファイルが含まれている場合は、[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 構成

ビルドのグループを 1 つの操作として実行できます。詳細については、「AWS CodeBuild でのバッチビルド」を参照してください。

バッチ構成の定義

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

Batch サービスロール

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

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

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

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

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

  • ビルドの役割を与える StartBuildStopBuild、および 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] (ビルドの開始と終了時にソースプロバイダーにビルドステータスをレポートする) が選択されている場合のみです。

集約されたビルド

これを選択して、バッチ内にあるすべてのビルドのステータスを単一のステータスレポートにまとめます。

個々のビルド

これを選択して、バッチ内にあるすべてのビルドのビルドステータスが個別に報告されるようにします。

アーティファクト

[Type] (タイプ)

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

  • ビルド出力アーティファクトを作成しない場合は、[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 の構文 の説明を参照してください。

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

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

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

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

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

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

追加設定
暗号化キー

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

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

  • カスタマー管理のキーを使用してビルド出力アーティファクトを暗号化するには、[暗号化キー] に KMS キーの 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 の構文」を参照してください。キャッシングの詳細については、「AWS CodeBuild でのキャッシュのビルド」を参照してください。

ログ

作成するログを選択します。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 ログを暗号化しない場合は、選択します。