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

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

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

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

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 によってトリガーされた場合、この設定への変更を有効にするには、新しいコミットをリポジトリにプッシュする必要があります。

プライマリソースウェブフックイベント で、コード変更がこのリポジトリにプッシュされるたびにソースコードを構築する場合は、コード変更がこのリポジトリにプッシュされるたびに再構築を選択します。 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] (ビルドの開始と終了時にソースプロバイダーにビルドステータスをレポートする) を選択します。

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

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

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

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

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

プライマリソースウェブフックイベント で、コード変更がこのリポジトリにプッシュされるたびにソースコードを構築する場合は、コード変更がこのリポジトリにプッシュされるたびに再構築を選択します。 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] (ビルドの開始と終了時にソースプロバイダーにビルドステータスをレポートする) を選択します。

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

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

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

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

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

安全でない SSL

Enterprise プロジェクトリポジトリへの接続中に SSL 警告を無視するには、安全でない SSL GitHub を有効にするを選択します。

プライマリソースのウェブフックイベント で、コード変更がこのリポジトリにプッシュされるたびにソースコードを構築する場合は、コード変更がこのリポジトリにプッシュされるたびに再構築を選択します。 CodeBuild Webhook およびフィルターグループの詳細については、「GitHub ウェブフックイベント」を参照してください。

GitLab
Connection

を使用して GitLab アカウントを接続し AWS CodeConnections、その接続を使用してサードパーティーのリポジトリをビルドプロジェクトのソースとして関連付けます。

デフォルト接続 またはカスタム接続 を選択します。

デフォルトの接続では、すべてのプロジェクトにデフォルトの GitLab 接続が適用されます。カスタム接続は、アカウントのデフォルト設定を上書きするカスタム GitLab 接続を適用します。

デフォルト接続

アカウントに関連付けられているデフォルトの接続の名前。

プロバイダーへの接続をまだ作成していない場合は、への接続 GitLabを作成する (コンソール)「」の手順を参照してください。

カスタム接続

使用するカスタム接続の名前を選択します。

プロバイダーへの接続をまだ作成していない場合は、への接続 GitLabを作成する (コンソール)「」の手順を参照してください。

リポジトリ

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

ソースバージョン

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

注記

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

Git クローンの深度

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

ビルドステータス

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

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

GitLab Self Managed
Connection

を使用して GitLab アカウントを接続し AWS CodeConnections、その接続を使用してサードパーティーのリポジトリをビルドプロジェクトのソースとして関連付けます。

デフォルト接続 またはカスタム接続 を選択します。

デフォルトの接続では、すべてのプロジェクトにデフォルトの GitLab セルフマネージド接続が適用されます。カスタム接続は、アカウントのデフォルト設定を上書きするカスタム GitLab セルフマネージド接続を適用します。

デフォルト接続

アカウントに関連付けられているデフォルトの接続の名前。

プロバイダーへの接続をまだ作成していない場合は、「 デベロッパーツールコンソールユーザーガイド」の GitLab 「自己管理型 への接続を作成する」を参照してください。

カスタム接続

使用するカスタム接続の名前を選択します。

プロバイダーへの接続をまだ作成していない場合は、「 デベロッパーツールコンソールユーザーガイド」の GitLab 「自己管理型 への接続を作成する」を参照してください。

リポジトリ

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

ソースバージョン

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

注記

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

Git クローンの深度

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

ビルドステータス

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

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

環境

プロビジョニングモデル

次のいずれかを行います。

  • によって管理されるオンデマンドフリートを使用するには AWS CodeBuild、オンデマンド を選択します。オンデマンドフリートでは、 CodeBuild はビルドのコンピューティングを提供します。マシンはビルドが終了すると破棄されます。オンデマンドフリートはフルマネージド型で、需要の急増にも対応できる自動スケーリング機能を備えています。

  • によって管理されるリザーブドキャパシティフリートを使用するには AWS CodeBuild、リザーブドキャパシティ を選択し、フリート名 を選択します。リザーブドキャパシティフリートでは、ビルド環境に合わせて専有インスタンスのセットを設定します。これらのマシンはアイドル状態のままで、ビルドやテストをすぐに処理できる状態になり、ビルド時間を短縮します。リザーブドキャパシティフリートでは、マシンは常に稼働しており、プロビジョニングされている間はコストが発生し続けます。

詳細については、「でのリザーブドキャパシティの操作 AWS CodeBuild」を参照してください。

環境イメージ

次のいずれかを行います。

  • によって管理される Docker イメージを使用するには AWS CodeBuild、マネージドイメージ を選択し、オペレーティングシステム ランタイム (s)イメージ イメージバージョン から選択します。利用可能な場合は、[環境タイプ] から選択します。

  • 別の 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 リポジトリ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の を上書きします。

コンピューティング

次のいずれかを行います。

  • EC2 コンピューティングを使用するには、EC2 を選択します。EC2 コンピューティングは、アクションの実行中に最適化された柔軟性を提供します。

  • Lambda コンピューティングを使用するには、Lambda を選択します。Lambda コンピューティングは、ビルドの起動速度を最適化します。Lambda は、起動のレイテンシーが低いため、ビルドの高速化をサポートします。Lambda も自動的にスケーリングするため、ビルドはキュー内で実行を待機しません。詳細については、「での AWS Lambda コンピューティングの使用 AWS CodeBuild」を参照してください。

サービスロール

次のいずれかを行います。

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

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

注記

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

追加設定
タイムアウト

5 分から 8 時間の間の値を指定し、その後、完了しないとビルドを CodeBuild 停止します。[hours] と [minutes] を空白のままにすると、デフォルト値の 60 分が使用されます。

特権付与

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

注記

デフォルトでは、Docker デーモンは VPC 以外のビルドで有効になっています。VPC ビルドに Docker コンテナを使用する場合は、Docker Docs ウェブサイトの「ランタイム特権と Linux 機能」を参照して、特権モードを有効にします。また、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

VPC CodeBuild を使用する場合:

  • VPC の場合、 が CodeBuild 使用する VPC ID を選択します。

  • VPC サブネット で、 が CodeBuild 使用するリソースを含むサブネットを選択します。

  • VPC セキュリティグループ で、 CodeBuild が VPCs内のリソースへのアクセスを許可するために使用するセキュリティグループを選択します。

詳細については、「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] に設定します。

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

Amazon EC2 Systems Manager パラメータストアを使用する場合は、[Type (タイプ)] で、[Parameter (パラメータ)] を選択します。名前に、参照 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 アクションを許可する必要があります。以前に新しいサービスロールを選択した場合、 はビルドプロジェクトのデフォルトのサービスロールにこのアクション 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] を選択します。名前に、参照 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 アクションを許可する必要があります。以前に新しいサービスロールを選択した場合、 はビルドプロジェクトのデフォルトのサービスロールにこのアクション 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] (サービスロール) で、サービスロールを選択します。

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

  • ビルドの役割を与える StartBuildStopBuild、および RetryBuild アクセス権限を使用すると、単一のビルドが buildspec を介してより多くのビルドを開始することができます。

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

バッチに使用できる計算タイプ

バッチに使用できる計算タイプを選択します。該当するものをすべて選択します。

バッチで許可される最大ビルド

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

バッチのタイムアウト

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

アーティファクトの結合

[Combine all artifacts from batch into a single location] (バッチのすべてのアーチファクト) を 1 つの場所に結合するを選択して、バッチのすべてのアーチファクトを単一の場所に結合します。

バッチレポートモード

バッチビルドに対して望ましいビルドステータスレポートモードを選択します。

注記

このフィールドは、プロジェクトソースが Bitbucket GitHub、、または GitHub Enterprise の場合にのみ使用でき、ビルドの開始と終了がソース で選択されたときにビルドステータスをソースプロバイダーに報告します

集約されたビルド

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

個々のビルド

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

アーティファクト

タイプ

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

  • ビルド出力アーティファクトを作成しない場合は、[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 ログ

CloudWatch ログを選択します。

グループ名

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

ストリーム名

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

S3

Amazon S3 ログが必要な場合は、以下のようになります。

S3 ログ

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

バケット

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

パスプレフィックス

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

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

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