翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# ビルドプロジェクト
*ビルドプロジェクト*には、ビルドの実行方法に関する情報が含まれています。これには、ソースコードの取得先、使用するビルド環境、実行するビルドコマンド、ビルド出力の格納先が含まれます。
ビルドプロジェクトを操作して以下のタスクを実行できます。
**Topics**
+ [
# でのビルドプロジェクトの作成AWS CodeBuild
](create-project.md)
+ [
# 通知ルールの作成
](notification-rule-create.md)
+ [
# でビルドプロジェクト設定を変更する AWS CodeBuild
](change-project.md)
+ [
# CodeBuild の複数のアクセストークン
](multiple-access-tokens.md)
+ [
# AWS CodeBuild でビルドプロジェクトを削除
](delete-project.md)
+ [
# パブリックビルドプロジェクトの URL を取得
](public-builds.md)
+ [
# ビルドプロジェクトを共有
](project-sharing.md)
+ [
# ビルドプロジェクトをタグ付け
](how-to-tag-project.md)
+ [
# でランナーを使用する AWS CodeBuild
](runners.md)
+ [
# でウェブフックを使用する AWS CodeBuild
](webhooks.md)
+ [
# でビルドプロジェクトの詳細を表示する AWS CodeBuild
](view-project-details.md)
+ [
# でビルドプロジェクト名を表示する AWS CodeBuild
](view-project-list.md)
# でのビルドプロジェクトの作成AWS CodeBuild
ビルドプロジェクトを作成するには、AWS CodeBuild コンソール、AWS CLI、または AWS SDK を使用できます。
**Topics**
+ [
## 前提条件
](#create-project-prerequisites)
+ [
## ビルドプロジェクトの作成 (コンソール)
](#create-project-console)
+ [
## ビルドプロジェクトの作成 (AWS CLI)
](#create-project-cli)
+ [
## ビルドプロジェクトの作成 (AWS SDK)
](#create-project-sdks)
+ [
## ビルドプロジェクトの作成 (CloudFormation)
](#create-project-cloud-formation)
## 前提条件
ビルドプロジェクトを作成する前に、[ビルドを計画する](planning.md) の質問に回答します。
## ビルドプロジェクトの作成 (コンソール)
AWS CodeBuild コンソール ([https://console.aws.amazon.com/codesuite/codebuild/home](https://console.aws.amazon.com/codesuite/codebuild/home)) を開きます。
CodeBuild の情報ページが表示された場合、**ビルドプロジェクトを作成する**を選択します。それ以外の場合は、ナビゲーションペインで**ビルド**を展開し、**[ビルドプロジェクト] **を選択し、次に **[Create build project (ビルドプロジェクトの作成)] **を選択します。
[**Create build project (ビルドプロジェクトの作成)**] を選択します。
次のセクションに入力します。完了したら、ページの下部にある **[Create build project]** (ビルドプロジェクトを作成する) を選択します。
**Topics**
+ [
### プロジェクトの設定
](#create-project-console-project-config)
+ [
### ソース
](#create-project-console-source)
+ [
### 環境
](#create-project-console-environment)
+ [
### Buildspec
](#create-project-console-buildspec)
+ [
### Batch 構成
](#create-project-console-batch-config)
+ [
### アーティファクト
](#create-project-console-artifacts)
+ [
### ログ
](#create-project-console-logs)
### プロジェクトの設定
**Project name**
このビルドプロジェクトの名前を入力します。ビルドプロジェクトの名前は、各 AWS アカウントで一意である必要があります。
**説明**
また、他のユーザーがこのプロジェクトの使用目的を理解できるように、ビルドプロジェクトの説明を任意で指定することもできます。
**ビルドバッジ**
(オプション)**[Enable build badge]** (ビルドバッジを有効にする) を選択すると、プロジェクトのビルドステータスが表示可能および埋め込み可能になります。詳細については、「[ビルドバッジサンプル](sample-build-badges.md)」を参照してください。
ソースプロバイダーが Amazon S3 の場合、ビルドバッジは適用されません。
**同時ビルド制限を有効にする**
(オプション) このプロジェクトで同時ビルド数を制限するには、次の手順を実行します。
1. **[Restrict number of concurrent builds this project can start]** (このジョブで許可される同時実行の最大数を設定) を選択します。
1. **[Concurrent build limit]** (同時ビルド制限) で、このジョブで許可される同時実行の最大数を設定します。この制限は、アカウントに設定された同時ビルド制限より大きくすることはできません。アカウント制限を超える数値を入力しようとすると、エラーメッセージが表示されます。
新しいビルドは、現在のビルド数がこの制限以下の場合にのみ開始されます。現在のビルドカウントがこの制限を満たす場合、新しいビルドはスロットルされ、実行されません。
**追加情報**
(オプション) [**タグ**] に、サポート対象の AWS のサービスで使用するタグの名前と値を入力します。[**Add row**] を使用して、タグを追加します。最大 50 個のタグを追加できます。
### ソース
**ソースプロバイダー**
ソースコードプロバイダーのタイプを選択します。次のリストを使用して、ソースプロバイダーに関する適切な選択を行います。
CodeBuild は Bitbucket サーバーをサポートしていません。
------
#### [ Amazon S3 ]
**バケット**
ソースコードが格納されている入力バケットの名前を選択します。
**S3 オブジェクトキーまたは S3 フォルダ**
ZIP ファイルの名前、またはソースコードを含むフォルダへのパスを入力します。S3 バケットの中身をすべてダウンロードするには、スラッシュ記号 (/) を入力します。
**ソースバージョン**
入力ファイルのビルドを表すオブジェクトのバージョン IDを入力。詳細については、「[を使用したソースバージョンサンプル AWS CodeBuild](sample-source-version.md)」を参照してください。
------
#### [ CodeCommit ]
**リポジトリ**
使用するリポジトリを選択します。
**参照タイプ**
**[Branch] **(ブランチ) または** [Git tag]** (Git タグ) を選択するか、**[Commit ID]** (コミット ID) を入力して、ソースコードのバージョンを指定します。詳細については、「[を使用したソースバージョンサンプル AWS CodeBuild](sample-source-version.md)」を参照してください。
`811dd1ba1aba14473856cee38308caed7190c0d` または `5392f7` のように、コミット ID と似ていない Git ブランチ名を選択することをお勧めします。これにより、Git checkout が実際のコミットと衝突するのを防ぐことができます。
**Git クローンの深度**
選択して、指定されるコミット数で切り捨てられる履歴の浅いクローンを作成します。完全クローンを希望する場合には、[**Full (完全)**] を選択します。
**Git サブモジュール**
リポジトリに Git サブモジュールを含める場合は、[**Git サブモジュールを使用する**] を選択します。
------
#### [ Bitbucket ]
**[認証情報]**
**[デフォルトソース認証情報]** または **[カスタムソース認証情報]** を選択し、手順に従ってデフォルトソース認証情報を管理するか、ソース認証情報をカスタマイズします。
**[接続タイプ]**
**[CodeConnections]**、**[OAuth]**、**[アプリパスワード]**、または **[個人用アクセストークン]** を選択して CodeBuild に接続します。
**接続**
Bitbucket 接続または Secrets Manager シークレットを選択して、指定した接続タイプ経由で接続します。
**リポジトリ**
**[Bitbucket アカウントのリポジトリ]** または **[パブリックリポジトリ]** を選択し、リポジトリ URL を入力します。
**ソースバージョン**
ブランチ、コミット ID、タグあるいはリファレンスとコミット ID を入力します。詳細については、「[を使用したソースバージョンサンプル AWS CodeBuild](sample-source-version.md)」を参照してください。
`811dd1ba1aba14473856cee38308caed7190c0d` または `5392f7` のように、コミット ID と似ていない Git ブランチ名を選択することをお勧めします。これにより、Git checkout が実際のコミットと衝突するのを防ぐことができます。
**Git クローンの深度**
[**Git クローンの深さ**] を選択して、指定されるコミット数で切り捨てられる履歴の浅いクローンを作成します。完全クローンを希望する場合には、[**Full (完全)**] を選択します。
**Git サブモジュール**
リポジトリに Git サブモジュールを含める場合は、[**Git サブモジュールを使用する**] を選択します。
**ビルドステータス**
ビルドの開始と終了のステータスをソースプロバイダーにレポートする場合は、**[Report build statuses to source provider when your builds start and finish]** (ビルドの開始と終了時にソースプロバイダーにビルドステータスをレポートする) を選択します。
ソースプロバイダにビルド状態を報告できるようにするには、ソースプロバイダに関連付けられたユーザーがリポジトリへの書き込みアクセス権を持っている必要があります。ユーザーが書き込みアクセス権を持っていない場合、ビルドのステータスは更新できません。詳細については、「[ソースプロバイダーのアクセス](access-tokens.md)」を参照してください。
**[Status context]** (ステータスコンテキスト) に、Bitbucket コミットステータスの `name` パラメータに使用する値を記入します。詳細については、Bitbucket API ドキュメントの「[ビルド](https://developer.atlassian.com/bitbucket/api/2/reference/resource/repositories/%7Bworkspace%7D/%7Brepo_slug%7D/commit/%7Bnode%7D/statuses/build)」を参照してください。
**[Target URL]** (ターゲットURL) に、Bitbucket コミットステータスの `url` パラメータに使用する値を記入します。詳細については、Bitbucket API ドキュメントの「[ビルド](https://developer.atlassian.com/bitbucket/api/2/reference/resource/repositories/%7Bworkspace%7D/%7Brepo_slug%7D/commit/%7Bnode%7D/statuses/build)」を参照してください。
webhook によってトリガーされたビルドのステータスは常にソースプロバイダーにレポートされます。コンソールから開始されたビルドのステータスまたはソースプロバイダーに報告された API 呼び出しを取得するには、この設定を選択する必要があります。
プロジェクトのビルドが webhook によってトリガーされた場合、この設定への変更を有効にするには、新しいコミットをリポジトリにプッシュする必要があります。
[**Primary source webhook events**] (プライマリソース Webhook イベント) で [**Rebuild every time a code change is pushed to this repository**] (コード変更がこのリポジトリにプッシュされるたび再構築) を選択して、コード変更がこのリポジトリにプッシュされるたびに CodeBuild で再構築します。Webhook およびフィルターグループの詳細については、「[Bitbucket ウェブフックイベント](bitbucket-webhook.md)」を参照してください。
------
#### [ GitHub ]
**認証情報**
**[デフォルトソース認証情報]** または **[カスタムソース認証情報]** を選択し、手順に従ってデフォルトソース認証情報を管理するか、ソース認証情報をカスタマイズします。
**[接続タイプ]**
**[GitHub アプリ]**、**[OAuth]**、または **[個人用アクセストークン]** を選択して CodeBuild に接続します。
**接続**
GitHub 接続または Secrets Manager シークレットを選択して、指定した接続タイプ経由で接続します。
**リポジトリ**
**[GitHub アカウントのリポジトリ]**、**[パブリックリポジトリ]**、または **[GitHub スコープ付きウェブフック]** を選択し、リポジトリ URL を入力します。
**ソースバージョン**
ブランチ、コミット ID、タグあるいはリファレンスとコミット ID を入力します。詳細については、「[を使用したソースバージョンサンプル AWS CodeBuild](sample-source-version.md)」を参照してください。
`811dd1ba1aba14473856cee38308caed7190c0d` または `5392f7` のように、コミット ID と似ていない Git ブランチ名を選択することをお勧めします。これにより、Git checkout が実際のコミットと衝突するのを防ぐことができます。
**Git クローンの深度**
[**Git クローンの深さ**] を選択して、指定されるコミット数で切り捨てられる履歴の浅いクローンを作成します。完全クローンを希望する場合には、[**Full (完全)**] を選択します。
**Git サブモジュール**
リポジトリに Git サブモジュールを含める場合は、[**Git サブモジュールを使用する**] を選択します。
**ビルドステータス**
ビルドの開始と終了のステータスをソースプロバイダーにレポートする場合は、**[Report build statuses to source provider when your builds start and finish]** (ビルドの開始と終了時にソースプロバイダーにビルドステータスをレポートする) を選択します。
ソースプロバイダにビルド状態を報告できるようにするには、ソースプロバイダに関連付けられたユーザーがリポジトリへの書き込みアクセス権を持っている必要があります。ユーザーが書き込みアクセス権を持っていない場合、ビルドのステータスは更新できません。詳細については、「[ソースプロバイダーのアクセス](access-tokens.md)」を参照してください。
**[Status context]** (ステータスコンテキスト) に、GitHub コミットステータスの `context`パラメータに使用する値を記入します。ｑ 詳細については、GitHub デベロッパーガイドの「[コミットステータスの作成](https://developer.github.com/v3/repos/statuses/#create-a-commit-status)」を参照してください。
**[Target URL] **(ターゲット URL) に、 GitHub コミットステータスの `target_url` パラメータに使用する値を記入します。詳細については、GitHub デベロッパーガイドの「[コミットステータスの作成](https://developer.github.com/v3/repos/statuses/#create-a-commit-status)」を参照してください。
webhook によってトリガーされたビルドのステータスは、常にソースプロバイダーにレポートされます。コンソールから開始されたビルドのステータスまたはソースプロバイダーに報告された API 呼び出しを取得するには、この設定を選択する必要があります。
プロジェクトのビルドが webhook によってトリガーされた場合、この設定への変更を有効にするには、新しいコミットをリポジトリにプッシュする必要があります。
[**Primary source webhook events**] (プライマリソース Webhook イベント) で [**Rebuild every time a code change is pushed to this repository**] (コード変更がこのリポジトリにプッシュされるたび再構築) を選択して、コード変更がこのリポジトリにプッシュされるたびに CodeBuild で再構築します。Webhook およびフィルターグループの詳細については、「[GitHub ウェブフックイベント](github-webhook.md)」を参照してください。
------
#### [ GitHub Enterprise Server ]
**認証情報**
**[デフォルトソース認証情報]** または **[カスタムソース認証情報]** を選択し、手順に従ってデフォルトソース認証情報を管理するか、ソース認証情報をカスタマイズします。
**[接続タイプ]**
**[CodeConnections]** または **[個人用アクセストークン]** を選択して CodeBuild に接続します。
**接続**
GitHub Enterprise 接続または Secrets Manager シークレットを選択して、指定した接続タイプ経由で接続します。
**リポジトリ**
**[自分の GitHub Enterprise アカウントのレポジトリ]** または **[GitHub Enterprise スコープ付きウェブフック]** を選択し、リポジトリ URL を入力します。
**ソースバージョン**
プルリクエスト、ブランチ、コミット ID、コミット ID、参照、およびコミット ID を入力します。詳細については、「[を使用したソースバージョンサンプル AWS CodeBuild](sample-source-version.md)」を参照してください。
`811dd1ba1aba14473856cee38308caed7190c0d` または `5392f7` のように、コミット ID と似ていない Git ブランチ名を選択することをお勧めします。これにより、Git checkout が実際のコミットと衝突するのを防ぐことができます。
**Git クローンの深度**
[**Git クローンの深さ**] を選択して、指定されるコミット数で切り捨てられる履歴の浅いクローンを作成します。完全クローンを希望する場合には、[**Full (完全)**] を選択します。
**Git サブモジュール**
リポジトリに Git サブモジュールを含める場合は、[**Git サブモジュールを使用する**] を選択します。
**ビルドステータス**
ビルドの開始と終了のステータスをソースプロバイダーにレポートする場合は、**[Report build statuses to source provider when your builds start and finish]** (ビルドの開始と終了時にソースプロバイダーにビルドステータスをレポートする) を選択します。
ソースプロバイダにビルド状態を報告できるようにするには、ソースプロバイダに関連付けられたユーザーがリポジトリへの書き込みアクセス権を持っている必要があります。ユーザーが書き込みアクセス権を持っていない場合、ビルドのステータスは更新できません。詳細については、「[ソースプロバイダーのアクセス](access-tokens.md)」を参照してください。
**[Status context]** (ステータスコンテキスト) に、GitHub コミットステータスの `context`パラメータに使用する値を記入します。ｑ 詳細については、GitHub デベロッパーガイドの「[コミットステータスの作成](https://developer.github.com/v3/repos/statuses/#create-a-commit-status)」を参照してください。
**[Target URL] **(ターゲット URL) に、 GitHub コミットステータスの `target_url` パラメータに使用する値を記入します。詳細については、GitHub デベロッパーガイドの「[コミットステータスの作成](https://developer.github.com/v3/repos/statuses/#create-a-commit-status)」を参照してください。
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 ウェブフックイベント](github-webhook.md)」を参照してください。
------
#### [ GitLab ]
**[認証情報]**
**[デフォルトソース認証情報]** または **[カスタムソース認証情報]** を選択し、手順に従ってデフォルトソース認証情報を管理するか、ソース認証情報をカスタマイズします。
**[接続タイプ]**
**[CodeConnections]** は、GitLab を CodeBuild に接続するために使用されます。
**接続**
CodeConnections 経由で接続する GitLab 接続を選択します。
**リポジトリ**
使用するリポジトリを選択します。
**ソースバージョン**
プルリクエスト ID、ブランチ、コミット ID、タグ、または参照およびコミット ID を入力します。詳細については、「[を使用したソースバージョンサンプル AWS CodeBuild](sample-source-version.md)」を参照してください。
`811dd1ba1aba14473856cee38308caed7190c0d` または `5392f7` のように、コミット ID と似ていない Git ブランチ名を選択することをお勧めします。これにより、Git checkout が実際のコミットと衝突するのを防ぐことができます。
**Git クローンの深度**
[**Git クローンの深さ**] を選択して、指定されるコミット数で切り捨てられる履歴の浅いクローンを作成します。完全クローンを希望する場合には、[**Full (完全)**] を選択します。
**ビルドステータス**
ビルドの開始と終了のステータスをソースプロバイダーにレポートする場合は、**[Report build statuses to source provider when your builds start and finish]** (ビルドの開始と終了時にソースプロバイダーにビルドステータスをレポートする) を選択します。
ソースプロバイダにビルド状態を報告できるようにするには、ソースプロバイダに関連付けられたユーザーがリポジトリへの書き込みアクセス権を持っている必要があります。ユーザーが書き込みアクセス権を持っていない場合、ビルドのステータスは更新できません。詳細については、「[ソースプロバイダーのアクセス](access-tokens.md)」を参照してください。
------
#### [ GitLab Self Managed ]
**[認証情報]**
**[デフォルトソース認証情報]** または **[カスタムソース認証情報]** を選択し、手順に従ってデフォルトソース認証情報を管理するか、ソース認証情報をカスタマイズします。
**[接続タイプ]**
**[CodeConnections]** は、GitLab セルフマネージドを CodeBuild に接続するために使用されます。
**接続**
CodeConnections 経由で接続する GitLab セルフマネージド接続を選択します。
**リポジトリ**
使用するリポジトリを選択します。
**ソースバージョン**
プルリクエスト ID、ブランチ、コミット ID、タグ、または参照およびコミット ID を入力します。詳細については、「[を使用したソースバージョンサンプル AWS CodeBuild](sample-source-version.md)」を参照してください。
`811dd1ba1aba14473856cee38308caed7190c0d` または `5392f7` のように、コミット ID と似ていない Git ブランチ名を選択することをお勧めします。これにより、Git checkout が実際のコミットと衝突するのを防ぐことができます。
**Git クローンの深度**
[**Git クローンの深さ**] を選択して、指定されるコミット数で切り捨てられる履歴の浅いクローンを作成します。完全クローンを希望する場合には、[**Full (完全)**] を選択します。
**ビルドステータス**
ビルドの開始と終了のステータスをソースプロバイダーにレポートする場合は、**[Report build statuses to source provider when your builds start and finish]** (ビルドの開始と終了時にソースプロバイダーにビルドステータスをレポートする) を選択します。
ソースプロバイダにビルド状態を報告できるようにするには、ソースプロバイダに関連付けられたユーザーがリポジトリへの書き込みアクセス権を持っている必要があります。ユーザーが書き込みアクセス権を持っていない場合、ビルドのステータスは更新できません。詳細については、「[ソースプロバイダーのアクセス](access-tokens.md)」を参照してください。
------
### 環境
**[プロビジョニングモデル]**
次のいずれかを行ってください。
+ AWS CodeBuild が管理するオンデマンドフリートを使用するには、**[オンデマンド]** を選択します。オンデマンドフリートでは、CodeBuild がビルドのコンピューティングを行います。マシンはビルドが終了すると破棄されます。オンデマンドフリートはフルマネージド型で、需要の急増にも対応できる自動スケーリング機能を備えています。
+ AWS CodeBuild が管理するリザーブドキャパシティフリートを使用するには、**[リザーブドキャパシティ]** を選択し、**[フリート名]** を選択します。リザーブドキャパシティフリートでは、ビルド環境に合わせて専有インスタンスのセットを設定します。これらのマシンはアイドル状態のままで、ビルドやテストをすぐに処理できる状態になり、ビルド時間を短縮します。リザーブドキャパシティフリートでは、マシンは常に稼働しており、プロビジョニングされている間はコストが発生し続けます。
詳細については、[リザーブドキャパシティキャパシティフリートでビルドを実行](fleets.md) を参照してください。
**環境イメージ**
次のいずれかを行ってください。
+ 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 レポジトリ**] および [**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 とは](https://docs.aws.amazon.com/secretsmanager/latest/userguide/)」を参照してください。
CodeBuild はカスタムDocker イメージの「`ENTRYPOINT`」をオーバーライドします。
**コンピューティング**
次のいずれかを行ってください。
+ EC2 コンピューティングを使用するには、**[EC2]** を選択します。EC2 コンピューティングは、アクションの実行中に最適化された柔軟性を提供します。
+ Lambda コンピューティングを使用するには、**[Lambda]** を選択します。Lambda コンピューティングは、ビルドの起動速度を最適化します。Lambda は、起動レイテンシーが低いため、より高速なビルドをサポートします。また、Lambda は自動的にスケールされるため、ビルドはキュー内で実行を待機することはありません。詳細については、[AWS Lambda コンピューティングでビルドを実行する](lambda.md) を参照してください。
**サービスロール**
次のいずれかを行ってください。
+ CodeBuild サービスロールがない場合は、[**新しいサービスロール**] を選択します。[**Role name**] に、新しいロールの名前を入力します。
+ CodeBuild サービスロールがある場合は、**[Existing service role (既存のサービスロール)]** を選択します。[**Role ARN**] で、サービスロールを選択します。
コンソールでは、ビルドプロジェクトの作成時に CodeBuild サービスロールも作成できます。デフォルトでは、ロールはそのビルドプロジェクトでのみ使用できます。コンソールでは、このサービスロールを別のビルドプロジェクトと関連付けると、この別のビルドプロジェクトで使用できるようにロールが更新されます。サービスロールは最大 10 個のビルドプロジェクトで使用できます。
**追加設定**
**[自動再試行の制限]**
ビルドが失敗した後の追加の自動再試行回数を指定します。例えば、自動再試行の制限が 2 に設定されている場合、CodeBuild は `RetryBuild` API を呼び出して、さらに最大 2 回までビルドを自動的に再試行します。
**タイムアウト**
5 分～36 時間の間の値を指定します。この時間が経過してもビルドが完了していない場合、CodeBuild はビルドを停止します。[**hours**] と [**minutes**] を空白のままにすると、デフォルト値の 60 分が使用されます。
**特権付与**
(オプション) このビルドプロジェクトを使って Dockerイメージをビルドする場合にのみ、**[Docker イメージをビルドする場合、またはビルドで昇格された権限を取得する場合は、このフラグを有効にする]** を選択します。それ以外の場合、関連付けられているビルドで Docker デーモンと通信しようとすると、すべて失敗します。ビルドが Docker デーモンと連係動作できるように、Docker デーモンも起動する必要があります。これを行う 1 つの方法は、次のビルドコマンドを実行してビルドスペックの `install` フェーズで Docker デーモンを初期化することです。Docker をサポートする CodeBuild によって提供されるビルド環境イメージを選択した場合は、これらのコマンドを実行しないでください。
デフォルトでは、Docker デーモンは非 VPC ビルドで有効になっています。VPC ビルドに Docker コンテナを使用する場合は、Docker Docs ウェブサイトの「[Runtime Privilege and Linux Capabilities](https://docs.docker.com/engine/reference/run/#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 で を使用する](vpc-support.md)」を参照してください。
**コンピューティング**
使用可能なオプションの 1 つを選択します。
**レジストリ認証情報**
プロジェクトが非プライベートレジストリイメージで設定されている場合は、レジストリ認証情報を指定します。
この認証情報は、イメージがプライベートレジストリのイメージで上書きされている場合にのみ使用されます。
**環境変数**
[環境変数] で、名前と値を入力してから、ビルドによって使用される各環境変数の種類を選択します。
CodeBuild は AWS リージョンの環境変数を自動的に設定します。以下の環境変数を buildspec.yml に追加していない場合は、それらの変数を設定する必要があります。
+ AWS\$1ACCOUNT\$1ID
+ IMAGE\$1REPO\$1NAME
+ IMAGE\$1TAG
コンソールと 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 パラメータストア](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)」を参照してください。
ビルドプロジェクトが 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 reference-key in the buildspec file](build-spec-ref.md#secrets-manager-build-spec) を参照してください。
Secrets Manager を使用する場合は、「`/CodeBuild/`」で始まる名前でシークレットを保存することをお勧めします(たとえば、`/CodeBuild/dockerLoginPassword`)。詳細については、*AWS Secrets Managerユーザーガイド*の「[AWS Secrets Manager とは](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html)」を参照してください。
ビルドプロジェクトが 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:::/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) に関するリファレンス](build-spec-ref.md)」を参照してください。
### Batch 構成
ビルドのグループを 1 つの操作として実行できます。詳細については、「[ビルドをバッチで実行](batch-build.md)」を参照してください。
**バッチ構成の定義**
このプロジェクトでバッチビルドを許可する場合に選択します。
**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 の構文](build-spec-ref.md#build-spec-ref-syntax)」を参照してください。
+ [**Bucket name (バケット名)**] で、出力バケットの名前を選択します。
+ この手順の前の方で [**ビルドコマンドの挿入**] を選択した場合は、[**出力ファイル**] に、ビルド出力 ZIP ファイルまたはフォルダに格納するビルドのファイルの場所を入力します。複数の場所の場合は、各場所をコンマで区切ります (例: `appspec.yml, target/my-app.jar`)。詳細については、「`files`」で [buildspec の構文](build-spec-ref.md#build-spec-ref-syntax) の説明を参照してください。
+ ビルドアーティファクトを暗号化しない場合は、[**アーティファクト暗号化の削除**] を選択します。
アーティファクトのセカンダリセットごとに:
1. [**Artifact 識別子**] には、英数字とアンダースコアのみを使用して 128 文字未満の値を入力します。
1. [**アーティファクトの追加**] を選択します。
1. セカンダリアーティファクトを設定するには、前のステップに従います。
1. [**アーティファクトの保存**] を選択します。
**追加設定**
**暗号化キー**
次のいずれかを実行します。
+ アカウントの 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 の構文](build-spec-ref.md#build-spec-ref-syntax)」を参照してください。キャッシングの詳細については、「[パフォーマンスを向上させるためのキャッシュビルド](build-caching.md)」を参照してください。
### ログ
作成するログを選択します。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)
CodeBuild で AWS CLI を使用する方法の詳細については、「[コマンドラインリファレンス](cmd-ref.md)」を参照してください。
AWS CLI を使用して CodeBuild ビルドプロジェクトを作成するには、JSON 形式の[プロジェクト](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_Project.html)構造体を作成し、構造体に入力を行い、[https://docs.aws.amazon.com/cli/latest/reference/codebuild/create-project.html](https://docs.aws.amazon.com/cli/latest/reference/codebuild/create-project.html) コマンドを実行してプロジェクトを作成します。
### JSON ファイルの作成
`--generate-cli-skeleton` オプションを使用して、[https://docs.aws.amazon.com/cli/latest/reference/codebuild/create-project.html](https://docs.aws.amazon.com/cli/latest/reference/codebuild/create-project.html) コマンドでスケルトン JSON ファイルを作成します。
```
aws codebuild create-project --generate-cli-skeleton >
```
これにより、** で指定されるパスとファイル名で JSON ファイルが作成されます。
### JSON ファイルを入力します。
JSON データを次のように変更して、結果を保存します。
```
{
"name": "",
"description": "",
"source": {
"type": "CODECOMMIT" | "CODEPIPELINE" | "GITHUB" | "GITHUB_ENTERPRISE" | "GITLAB" | "GITLAB_SELF_MANAGED" | "BITBUCKET" | "S3" | "NO_SOURCE",
"location": "",
"gitCloneDepth": "",
"buildspec": "",
"InsecureSsl": "",
"reportBuildStatus": "",
"buildStatusConfig": {
"context": "",
"targetUrl": ""
},
"gitSubmodulesConfig": {
"fetchSubmodules": ""
},
"auth": {
"type": "",
"resource": ""
},
"sourceIdentifier": ""
},
"secondarySources": [
{
"type": "CODECOMMIT" | "CODEPIPELINE" | "GITHUB" | "GITHUB_ENTERPRISE" | "GITLAB" | "GITLAB_SELF_MANAGED" | "BITBUCKET" | "S3" | "NO_SOURCE",
"location": "",
"gitCloneDepth": "",
"buildspec": "",
"InsecureSsl": "",
"reportBuildStatus": "",
"auth": {
"type": "",
"resource": ""
},
"sourceIdentifier": ""
}
],
"secondarySourceVersions": [
{
"sourceIdentifier": "",
"sourceVersion": ""
}
],
"sourceVersion": "",
"artifacts": {
"type": "CODEPIPELINE" | "S3" | "NO_ARTIFACTS",
"location": "",
"path": "",
"namespaceType": "",
"name": "",
"overrideArtifactName": "",
"packaging": ""
},
"secondaryArtifacts": [
{
"type": "CODEPIPELINE" | "S3" | "NO_ARTIFACTS",
"location": "",
"path": "",
"namespaceType": "",
"name": "",
"packaging": "",
"artifactIdentifier": ""
}
],
"cache": {
"type": "",
"location": "",
"mode": [
""
]
},
"environment": {
"type": "LINUX_CONTAINER" | "LINUX_GPU_CONTAINER" | "ARM_CONTAINER" | "WINDOWS_SERVER_2019_CONTAINER" | "WINDOWS_SERVER_2022_CONTAINER",
"image": "",
"computeType": "BUILD_GENERAL1_SMALL" | "BUILD_GENERAL1_MEDIUM" | "BUILD_GENERAL1_LARGE" | "BUILD_GENERAL1_2XLARGE",
"certificate": "",
"environmentVariables": [
{
"name": "",
"value": "",
"type": ""
}
],
"registryCredential": [
{
"credential": "",
"credentialProvider": ""
}
],
"imagePullCredentialsType": "CODEBUILD" | "SERVICE_ROLE",
"privilegedMode": ""
},
"serviceRole": "",
"autoRetryLimit": ,
"timeoutInMinutes": ,
"queuedTimeoutInMinutes": ,
"encryptionKey": "",
"tags": [
{
"key": "",
"value": ""
}
],
"vpcConfig": {
"securityGroupIds": [
""
],
"subnets": [
""
],
"vpcId": ""
},
"badgeEnabled": "",
"logsConfig": {
"cloudWatchLogs": {
"status": "",
"groupName": "",
"streamName": ""
},
"s3Logs": {
"status": "",
"location": "",
"encryptionDisabled": ""
}
},
"fileSystemLocations": [
{
"type": "EFS",
"location": ":/",
"mountPoint": "",
"identifier": "",
"mountOptions": ""
}
],
"buildBatchConfig": {
"serviceRole": "",
"combineArtifacts": ,
"restrictions": {
"maximumBuildsAllowed": ,
"computeTypesAllowed": [
""
],
"fleetsAllowed": [
""
]
},
"timeoutInMins": ,
"batchReportMode": "REPORT_AGGREGATED_BATCH" | "REPORT_INDIVIDUAL_BUILDS"
},
"concurrentBuildLimit":
}
```
以下に置き換えます。
#### **.name**
必須。このビルドプロジェクトの名前。この名前は、AWS アカウントのすべてのビルドプロジェクトにわたって一意である必要があります。
#### **description**
オプション。このビルドの説明。
#### **ソース**
必須。このビルドプロジェクトのソースコード設定に関する情報が含まれている、[ProjectSource](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_ProjectSource.html) オブジェクト。`source` オブジェクトを追加したら、[**secondarySources**](#cli.secondarysources) を使用して最大 12 個のソースを追加できます。これらの設定には以下が含まれます。
source/**type**
必須。ビルドするソースコードを含むリポジトリのタイプ。有効な値を次に示します。
+ `CODECOMMIT`
+ `CODEPIPELINE`
+ `GITHUB`
+ `GITHUB_ENTERPRISE`
+ `GITLAB`
+ `GITLAB_SELF_MANAGED`
+ `BITBUCKET`
+ `S3`
+ `NO_SOURCE`
`NO_SOURCE` を使用すると、プロジェクトにはソースがないため、buildspec をファイルとして使用できません。代わりに、`buildspec` 属性を使用して buildspec に YAML 形式の文字列を指定する必要があります。詳細については、「[ソースなしでビルドプロジェクトを作成](no-source.md)」を参照してください。
source/**location**
** を `CODEPIPELINE` に設定しない場合は必須です。指定されたリポジトリタイプのソースコードの場所。
+ CodeCommit の場合は、ソースコードと buildspec ファイルが格納されているリポジトリの HTTPS クローン URL（例: `https://git-codecommit..amazonaws.com/v1/repos/`）。
+ Amazon S3 では、ビルド入力バケット名の後に、ソースコードと buildspec を含む ZIP ファイルのパスと名前が続きます。次に例を示します。
+ 入力バケットのルートにある ZIP ファイルの場合: `/.zip`。
+ 入力バケットのサブフォルダーにある ZIP ファイルの場合: `//.zip`。
+ GitHub の場合は、ソースコードと buildspec ファイルが格納されているリポジトリへの HTTPS クローン URL。URL には github.com が含まれている必要があります。AWS アカウントを GitHub アカウントに接続する必要があります。これを行うには、CodeBuild コンソールを使用してビルドプロジェクトを作成します。
+ [**Authorize application**] を選択します。(GitHub アカウントに接続した後、ビルドプロジェクトの作成を完了する必要はありません。CodeBuild コンソールを閉じることができます。)
+ GitHub Enterprise Server の場合は、ソースコードと buildspec ファイルを含むリポジトリへの HTTP または HTTPS クローン URL。また、AWS アカウントを GitHub Enterprise Server アカウントに接続する必要があります。これを行うには、CodeBuild コンソールを使用してビルドプロジェクトを作成します。
1. GitHub Enterprise Server で個人用アクセストークンを作成します。
1. このトークンをクリップボードにコピーし、CodeBuild プロジェクトの作成時に使用します。詳細については、GitHub Help ウェブサイトの [Creating a personal access token for the command line](https://help.github.com/articles/creating-a-personal-access-token-for-the-command-line/) を参照してください。
1. コンソールを使用して CodeBuild プロジェクトを作成する場合、[**ソース**] の [**ソースプロバイダー**] で [**GitHub Enterprise**] を選択します。
1. [**個人用アクセストークン**] には、クリップボードにコピーしたトークンを貼り付けます。[**トークンの保存**] を選択します。これで、CodeBuild アカウントが GitHub Enterprise Server アカウントに接続されました。
+ GitLab および GitLab セルフマネージドの場合は、ソースコードと buildspec ファイルが格納されているリポジトリへの HTTPS クローン URL です。GitLab を使用する場合は、URL に gitlab.com を含める必要があります。GitLab セルフマネージドを使用する場合、URL に gitlab.com を含める必要はありません。AWS アカウントを GitLab または GitLab セルフマネージドアカウントに接続する必要があります。これを行うには、CodeBuild コンソールを使用してビルドプロジェクトを作成します。
+ デベロッパーツールのナビゲーションペインで **[設定]**、**[接続]**、**[接続を作成]** の順に選択します。このページで、GitLab または GitLab セルフマネージド接続を作成し、**[GitLab に接続]** を選択します。
+ Bitbucket の場合は、ソースコードと buildspec ファイルが格納されているリポジトリへの HTTPS クローン URL。URL には bitbucket.org が含まれている必要があります。また、AWS アカウントを Bitbucket アカウントに接続する必要があります。これを行うには、CodeBuild コンソールを使用してビルドプロジェクトを作成します。
1. コンソールを使用して Bitbucket に接続 (または再接続) する場合は、Bitbucket の [**Confirm access to your account**] ページで、[**Grant access**] を選択します (Bitbucket アカウントに接続した後、ビルドプロジェクトの作成を完了する必要はありません。CodeBuild コンソールを閉じることができます。)
+ AWS CodePipeline の場合は、`location` に `source` 値を指定しないでください。CodePipeline ではパイプラインを作成するときに、パイプラインのソースステージでソースコードの場所を指定するため、この値は CodePipeline では無視されます。
source/**gitCloneDepth**
オプション。ダウンロードする履歴の深さ。最小値は 0 です。この値が 0、あるいは 25 より大きいか指定されていない場合、完全な履歴が各ビルドプロジェクトと共にダウンロードされます。ソースタイプが Amazon S3 である場合、この値はサポートされません。
source/**buildspec**
オプション。使用するビルド仕様定義またはファイル。この値が指定されていない場合や、空の文字列に設定されている場合、ソースコードのルートディレクトリに `buildspec.yml` ファイルが含まれている必要があります。この値が設定されている場合は、インラインのビルド仕様定義か、プライマリソースのルートディレクトリからの相対的な代替 buildspec ファイルへのパス、S3 バケットへのパスになります。バケットは、ビルドプロジェクトと同じ AWS リージョンに存在する必要があります。ARN を使用して buildspec ファイルを指定します（例: `arn:aws:s3:::/buildspec.yml`）。詳細については、「[buildspec ファイル名とストレージの場所](build-spec-ref.md#build-spec-ref-name-storage)」を参照してください。
source/**auth**
ビルドするソースコードにアクセスするための CodeBuild の承認設定に関する情報が含まれています。
source/auth/**type**
必須。使用する権限付与タイプ。有効な値は次のとおりです。
+ `OAUTH`
+ `CODECONNECTIONS`
+ `SECRETS_MANAGER`
source/auth/**resource**
オプション。指定した権限付与タイプに適用されるリソース値。これは Secrets Manager ARN または CodeConnections ARN になります。
source/**reportBuildStatus**
ビルドの開始と完了のステータスをソースプロバイダーに送信するかどうかを指定します。これを GitHub、GitHub Enterprise Server、または Bitbucket 以外のソースプロバイダーに対して設定すると、`invalidInputException` がスローされます。
ソースプロバイダにビルド状態を報告できるようにするには、ソースプロバイダに関連付けられたユーザーがリポジトリへの書き込みアクセス権を持っている必要があります。ユーザーが書き込みアクセス権を持っていない場合、ビルドのステータスは更新できません。詳細については、「[ソースプロバイダーのアクセス](access-tokens.md)」を参照してください。
source/**buildStatusConfig**
CodeBuild ビルドプロジェクトがソースプロバイダにビルドステータスを報告する方法を定義する情報が含まれています。このオプションは、ソースタイプが `GITHUB`、`GITHUB_ENTERPRISE`、または `BITBUCKET` の場合にのみ使用されます。
source/buildStatusConfig/**context**
Bitbucket リソースでは、このパラメータは、Bitbucket コミットステータスの `name` パラメータに使用されます。GitHub ソースでは、このパラメータは、GitHub コミットステータスの `context` パラメータに使用されます。
例えば、`context` には、CodeBuild 環境変数を使用したビルド番号と webhook トリガーが含まれます。
```
AWS CodeBuild sample-project Build #$CODEBUILD_BUILD_NUMBER - $CODEBUILD_WEBHOOK_TRIGGER
```
これにより、webhook プルリクエストイベントによってトリガーされた build \$124 では、コンテキストは次のようになります。
```
AWS CodeBuild sample-project Build #24 - pr/8
```
source/buildStatusConfig/**targetUrl**
Bitbucket リソースでは、このパラメータは、Bitbucket コミットステータスの `url` パラメータに使用されます。GitHub ソースでは、このパラメータは、GitHub コミットステータスの `target_url` パラメータに使用されます。
たとえば、「`targetUrl`」と「`https://aws.amazon.com/codebuild/`」とコミットステータスをこのURLにリンクします。
また、URL に情報を追加するには、CodeBuild 環境変数を `targetUrl` に含めることもできます。例えば、ビルド領域を URL に追加するには、`targetUrl` を以下に設定します:
```
"targetUrl": "https://aws.amazon.com/codebuild/?region=$AWS_REGION"
```
ビルド領域が `us-east-2` の場合、これは次のように展開されます。
```
https://aws.amazon.com/codebuild/?region=us-east-2
```
source/**gitSubmodulesConfig**
オプション。Git サブモジュール設定に関する情報。CodeCommit、GitHub、GitHub Enterprise Server、Bitbucket でのみ使用されます。
source/gitSubmodulesConfig/**fetchSubmodules**
リポジトリに Git サブモジュールを含める場合は、`fetchSubmodules` を `true` に設定します。含まれている Git サブモジュールは HTTPS として設定する必要があります。
source/**InsecureSsl**
オプション。GitHub Enterprise Server でのみ使用されます。GitHub Enterprise Server プロジェクトリポジトリに接続するときの TLS 警告を無視するには、この値を `true` に設定します。デフォルト値は `false` です。`InsecureSsl` は、テスト目的でのみ使用してください。本番環境では使用しないでください。
source/**sourceIdentifier**
プロジェクトソースのユーザー定義識別子。プライマリソースの場合、省略可能です。セカンダリソースでは必須です。
#### **secondarySources**
オプション。ビルドプロジェクトのセカンダリソースに関する情報が含まれている、[ProjectSource](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_ProjectSource.html) オブジェクトの配列。最大 12 個のセカンダリソースを追加できます。`secondarySources` オブジェクトは、[**ソース**](#cli.source) オブジェクトで使用されるのと同じプロパティを使用します。セカンダリソースオブジェクトでは、`sourceIdentifier` は必須です。
#### **secondarySourceVersions**
オプション。[ProjectSourceVersion](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_ProjectSourceVersion.html) オブジェクトの配列。`secondarySourceVersions` をビルドレベルで指定すると、これよりも優先されます。
#### **sourceVersion**
オプション。このプロジェクト用に構築するビルド入力のバージョン。指定しない場合、最新のバージョンが使用されます。指定した場合、次のいずれかであることが必要です。
+ CodeCommit の場合: 使用するコミット ID、ブランチ、または Git タグ。
+ GitHub の場合、ビルドするソースコードのバージョンに対応するコミット ID、プルリクエスト ID、ブランチ名、またはタグ名。プルリクエスト ID を指定する場合、`pr/pull-request-ID` (例: `pr/25`) 形式を使用する必要があります。ブランチ名を指定すると、ブランチの HEAD コミット ID が使用されます。指定しない場合は、デフォルトブランチの HEAD コミット ID が使用されます。
+ GitLab の場合、コミット ID、プルリクエスト ID、ブランチ名、タグ名、または参照およびコミット ID です。詳細については、「[を使用したソースバージョンサンプル AWS CodeBuild](sample-source-version.md)」を参照してください。
+ Bitbucket の場合、ビルドするソースコードのバージョンに対応するコミット ID、ブランチ名、またはタグ名。ブランチ名を指定すると、ブランチの HEAD コミット ID が使用されます。指定しない場合は、デフォルトブランチの HEAD コミット ID が使用されます。
+ Amazon S3 の場合、使用するビルド入力 ZIP ファイルを表すオブジェクトのバージョン ID。
`sourceVersion` をビルドレベルで指定した場合、そのバージョンはこの (プロジェクトレベルの) `sourceVersion` より優先されます。詳細については、「[を使用したソースバージョンサンプル AWS CodeBuild](sample-source-version.md)」を参照してください。
#### **artifacts**
必須。このビルドプロジェクトの出力アーティファクト設定に関する情報が含まれている、[ProjectArtifacts](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_ProjectArtifacts.html) オブジェクト。`artifacts` オブジェクトを追加したら、[secondaryArtifacts](#cli.secondaryartifacts) を使用して最大 12 個のアーティファクトを追加できます。これらの設定には以下が含まれます。
artifacts/**type**
必須。ビルド出力アーティファクトのタイプ。有効な値は次のとおりです。
+ `CODEPIPELINE`
+ `NO_ARTIFACTS`
+ `S3`
artifacts/**location**
`S3` アーティファクトタイプでのみ使用されます。他のアーティファクトタイプには使用されません。
前提条件で作成または識別した出力バケットの名前。
artifacts/**path**
`S3` アーティファクトタイプでのみ使用されます。他のアーティファクトタイプには使用されません。
ZIP ファイルまたはフォルダを配置する出力バケットのパス。`path` の値を指定しない場合、CodeBuild では `namespaceType` (指定されている場合) と `name` を使用して、ビルド出力 ZIP ファイルまたはフォルダのパスと名前を決定します。たとえば、`MyPath` を `path` に、`MyArtifact.zip` に `name` 指定すると、パスと名前は「`MyPath/MyArtifact.zip`」になります。
artifacts/**namespaceType**
`S3` アーティファクトタイプでのみ使用されます。他のアーティファクトタイプには使用されません。
ビルド出力 ZIP ファイルまたはフォルダの名前空間。有効な値は、`BUILD_ID` および `NONE` です。`BUILD_ID` を使用してビルド出力 ZIP ファイルまたはフォルダのパスにビルド ID を挿入します。それ以外の場合は、`NONE` を使用します。`namespaceType` の値を指定しない場合、CodeBuild では `path` (指定されている場合) と `name` を使用して、ビルド出力 ZIP ファイルまたはフォルダのパスと名前を決定します。たとえば、`MyPath` を `path` に、`BUILD_ID` を `namespaceType`、`MyArtifact.zip` に `name` 指定すると、パスと名前は「`MyPath/build-ID/MyArtifact.zip`」になります。
artifacts/**name**
`S3` アーティファクトタイプでのみ使用されます。他のアーティファクトタイプには使用されません。
`location` 内のビルド出力 ZIP ファイルまたはフォルダの名前。たとえば、`MyPath` を `path` に、`MyArtifact.zip` に `name` 指定すると、パスと名前は「`MyPath/MyArtifact.zip`」になります。
artifacts/**overrideArtifactName**
S3 アーティファクトタイプ でのみ使用されます。他のアーティファクトタイプには使用されません。
オプション。`true` に設定すると、buildspec ファイルの `artifacts` ブロックで指定された名前が、`name` を上書きします。詳細については、「[CodeBuild のビルド仕様に関するリファレンス](build-spec-ref.md)」を参照してください。
artifacts/**packaging**
`S3` アーティファクトタイプでのみ使用されます。他のアーティファクトタイプには使用されません。
オプション。アーティファクトをパッケージ化する方法を指定します。許可された値は次のとおりです:
なし
ビルドアーティファクトを含むフォルダを作成します。これは、デフォルト値です。
ZIP
ビルドアーティファクトを含む ZIP ファイルを作成します。
#### secondaryArtifacts
オプション。ビルドプロジェクトのセカンダリアーティファクト設定に関する情報が含まれている、[ProjectArtifacts](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_ProjectArtifacts.html) オブジェクトの配列。最大 12 個のセカンダリアーティファクトを追加できます。`secondaryArtifacts` は、[**artifacts**](#cli.artifacts) オブジェクトで使用されているのと同じ設定の多くを使用します。
#### cache
必須。このビルドプロジェクトのキャッシュ設定に関する情報が含まれている、[ProjectCache](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_ProjectCache.html) オブジェクト。詳細については、「[キャッシュビルド](build-caching.md)」を参照してください。
#### 環境
必須。このプロジェクトのビルド環境設定に関する情報が含まれている、[ProjectEnvironment](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_ProjectEnvironment.html) オブジェクト。設定は次のとおりです。
environment/**type**
必須。構築環境のタイプ。詳細については、*CodeBuild API リファレンス*の「[型](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_ProjectEnvironment.html#CodeBuild-Type-ProjectEnvironment-type)」を参照してください。
environment/**image**
必須。このビルド環境で使用される Docker イメージ識別子。通常、この識別子は *image-name*:*tag* として表されます。例えば、CodeBuild で Docker イメージの管理に使用する Docker リポジトリの場合、これは `aws/codebuild/standard:5.0` です。Docker Hub では、`maven:3.3.9-jdk-8` です。Amazon ECR では、`account-id.dkr.ecr.region-id.amazonaws.com/your-Amazon-ECR-repo-name:tag` です。詳細については、「[CodeBuild に用意されている Docker イメージ](build-env-ref-available.md)」を参照してください。
environment/**computeType**
必須。このビルド環境で使用されるコンピュートリソースを指定します。詳細については、*CodeBuild API リファレンス*の「[computeType](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_ProjectEnvironment.html#CodeBuild-Type-ProjectEnvironment-computeType)」を参照してください。
environment/**certificate**
オプション。Amazon S3 バケットの ARN、パスのプレフィックス、および PEM エンコードされた証明書を含むオブジェクトキー。オブジェクトキーとして、PEM エンコードされた証明書が含まれている .pem ファイルまたは .zip ファイルのいずれかを使用できます。たとえば、Amazon S3 バケット名が ``、パスのプレフィックスが ``、オブジェクトキー名が `` である場合、`certificate` に使用できる形式は `` または `arn:aws:s3:::` です。
environment/**environmentVariables**
オプション。このビルド環境に指定する環境変数が含まれている、[EnvironmentVariable](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_EnvironmentVariable.html) オブジェクトの配列。各環境変数は、オブジェクトとして表されます。`name`、`value`、および `type` の `name`、`value`、 および `type`。
コンソールと AWS CLI のユーザーはすべての環境変数を表示できます。環境変数の表示に懸念がない場合は、「`name`」を「`value`」および 「`type`」を「`PLAINTEXT`」に設定します。
Amazon EC2 Systems Manager パラメータストアまたは AWS Secrets Manager には、AWS アクセスキー ID、AWS シークレットアクセスキー、パスワードなどの機密値を持つ環境変数をパラメータとして保存することをお勧めします。`name` の場合、保存されているパラメータについては、CodeBuild の識別子を参照するように設定します。
Amazon EC2 Systems Manager パラメータストアを使用する場合、`value` には、パラメータストアに保存されているとおりにパラメータの名前を設定します。`type` を `PARAMETER_STORE` に設定します。`/CodeBuild/dockerLoginPassword` という名前のパラメータを使用するには、たとえば、「`name`」を「`LOGIN_PASSWORD`」に設定。`value` を `/CodeBuild/dockerLoginPassword` に設定します。`type` を `PARAMETER_STORE` に設定します。
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 パラメータストア](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)」を参照してください。
ビルドプロジェクトが 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 を使用する場合、`value` には、Secrets Manager に保存されているパラメータの名前を設定します。`type` を `SECRETS_MANAGER` に設定します。`/CodeBuild/dockerLoginPassword` という名前のシークレットを使用するには、たとえば、「`name`」を「`LOGIN_PASSWORD`」に設定。`value` を `/CodeBuild/dockerLoginPassword` に設定します。`type` を `SECRETS_MANAGER` に設定します。
Secrets Manager を使用する場合は、「`/CodeBuild/`」で始まる名前でシークレットを保存することをお勧めします(たとえば、`/CodeBuild/dockerLoginPassword`)。詳細については、*AWS Secrets Managerユーザーガイド*の「[AWS Secrets Manager とは](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html)」を参照してください。
ビルドプロジェクトが Secrets Manager パラメータストアに保存されているパラメータを参照する場合、ビルドプロジェクトのサービスロールで `secretsmanager:GetSecretValue` アクションを許可する必要があります。以前に **[New service role]** (新しいサービスロール) を選択した場合は、CodeBuild のビルドプロジェクトのデフォルトのサービスロールにこのアクションが含まれています。ただし [**既存のサービスロール**] を選択した場合は、このアクションをサービスロールに個別に含める必要があります。
ビルドプロジェクトが、`/CodeBuild/` で始まらないパラメータ名を持つ、Secrets Manager に保存されているパラメータを参照し、**[新しいサービスロール] **を選択した場合、`/CodeBuild/` で始まらないシークレット名にアクセスできるようにサービスロールを更新する必要があります。これは、サービスロールで、`/CodeBuild/` で始まるシークレット名にのみアクセスが許可されるためです。
[**新しいサービスロール**] を選択した場合、作成されるサービスロールには、Secrets Manager の `/CodeBuild/` 名前空間ですべてのシークレットを復号するアクセス許可が含まれます。
environment/**registryCredential**
オプション。プライベート Docker レジストリへのアクセスを提供する認証情報を指定する [RegistryCredential](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_RegistryCredential.html) オブジェクト。
environment/registryCredential/**credential**
AWS Managed Services を使用して作成された認証情報の ARN または名前を指定します。認証情報の名前を使用できるのは、認証情報が現在のリージョン内に存在する場合のみです。
environment/registryCredential/**credentialProvider**
唯一の有効な値は `SECRETS_MANAGER` です。
これを設定した場合:
+ `imagePullCredentials` を に設定する必要があります。`SERVICE_ROLE`
+ 選別されたイメージや Amazon ECR イメージは使用できません。
environment/**imagePullCredentialsType**
オプション。ビルドのイメージをプルするために CodeBuild で使用する認証情報のタイプ。2 つの有効な値があります。
CODEBUILD
`CODEBUILD` は、CodeBuild で独自の認証情報を使用することを指定します。CodeBuild サービスプリンシパルを信頼するには、Amazon ECR リポジトリポリシーを編集する必要があります。
SERVICE\$1ROLE
CodeBuild でビルドプロジェクトのサービスロールを使用することを指定します。
クロスアカウントまたはプライベートレジストリイメージを使用する場合は、`SERVICE_ROLE` の認証情報を使用する必要があります。CodeBuild の選別されたイメージを使用する場合は、`CODEBUILD` の認証情報を使用する必要があります。
environment/**privilegedMode**
このビルドプロジェクトを使用して Docker イメージをビルドする計画の場合のみ、`true` に設定します。それ以外の場合、関連付けられているビルドで Docker デーモンと通信しようとすると、すべて失敗します。ビルドが Docker デーモンと連係動作できるように、Docker デーモンも起動する必要があります。これを行う 1 つの方法は、次のビルドコマンドを実行して buildspec ファイルの `install` フェーズで Docker デーモンを初期化することです。Docker をサポートする CodeBuild によって提供されるビルド環境イメージを指定した場合は、これらのコマンドを実行しないでください。
デフォルトでは、Docker デーモンは非 VPC ビルドで有効になっています。VPC ビルドに Docker コンテナを使用する場合は、Docker Docs ウェブサイトの「[Runtime Privilege and Linux Capabilities](https://docs.docker.com/engine/reference/run/#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"
```
#### serviceRole
必須。CodeBuild がユーザーに代わってサービスとやり取りするために使用するサービスロールの ARN (例: `arn:aws:iam::account-id:role/role-name`)。
#### autoRetryLimit
オプション。ビルドが失敗した後、さらに自動で再試行する回数です。例えば、自動再試行の制限が 2 に設定されている場合、CodeBuild は `RetryBuild` API を呼び出して、さらに最大 2 回までビルドを自動的に再試行します。
#### timeoutInMinutes
オプション。5〜2,160 分 (36 時間) の分単位の時間。この時間が経過してもビルドが完了していない場合、CodeBuild はビルドを停止します。指定しない場合は、デフォルトの 60 が使用されます。CodeBuild がタイムアウトによりビルドを停止したかどうか、およびそのタイミングを確認するには、`batch-get-builds` コマンドを実行します。ビルドが停止しているかどうかを確認するには、出力で `buildStatus` の `FAILED` 値を調べます。ビルドがタイムアウトした時間を確認するには、 出力で `endTime` の`phaseStatus` 値に関連付けられている `TIMED_OUT` 値を調べます。
#### queuedTimeoutInMinutes
オプション。5〜480 分 (8 時間) の分単位の時間。この時間が経過すると、ビルドがキューされている場合に CodeBuild によってビルドが停止されます。指定しない場合は、デフォルトの 60 が使用されます。
#### encryptionKey
オプション。ビルド出力を暗号化するために CodeBuild で使用する AWS KMS key のエイリアスまたは ARN。エイリアスを指定する場合に、`arn:aws:kms:region-ID:account-ID:key/key-ID` 形式を使用し、エイリアスが存在する場合には、`alias/key-alias` 形式を使用します。指定しない場合は、Amazon S3 の AWS 管理 KMS キーが使用されます。
#### tags
オプション。このビルドプロジェクトに関連付けるタグを提供する [Tag](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_Tag.html) オブジェクトの配列。最大 50 個のタグを指定できます。これらのタグは、CodeBuild ビルドプロジェクトタグをサポートする任意の AWS のサービスで使用できます。各タグは、「`key`」と「`value`」オブジェクトとして表現されます。
#### vpcConfig
オプション。[VpcConfig](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_VpcConfig.html) オブジェクト。プロジェクトの VPC 設定に関する情報を含む。詳細については、「[Amazon Virtual Private Cloud AWS CodeBuild で を使用する](vpc-support.md)」を参照してください。
これらのプロパティには、次のものがあります。
vpcId
必須。CodeBuild で使用される VPC ID。リージョン内の VPC ID を一覧表示するには、次のコマンドを実行します。
```
aws ec2 describe-vpcs --region
```
サブネット
必須。CodeBuild で使用されるリソースを含むサブネット ID の配列。これらの ID を取得するには、次のコマンドを実行します。
```
aws ec2 describe-subnets --filters "Name=vpc-id,Values=" --region
```
securityGroupIds
必須。VPC 内のリソースへのアクセスを許可するために CodeBuild で使用されるセキュリティグループ ID の配列。これらの ID を取得するには、次のコマンドを実行します。
```
aws ec2 describe-security-groups --filters "Name=vpc-id,Values=" --
```
#### badgeEnabled
オプション。CodeBuild プロジェクトにビルドバッジを含めるかどうかを指定します。`true` に設定してビルドバッジを有効にするか、そうでない場合は `false` に設定します。詳細については、「[CodeBuild でのビルドバッジサンプル](sample-build-badges.md)」を参照してください。
#### logsConfig
このビルドのログが配置されている場所に関する情報が含まれている、[LogsConfig](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_LogsConfig.html) オブジェクト。
logsConfig/**cloudWatchLogs**
CloudWatch Logs へのログのプッシュに関する情報が含まれている、[CloudWatchLogsConfig](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_CloudWatchLogsConfig.html) オブジェクト。
logsConfig/**s3Logs**
Amazon S3 へのログのプッシュに関する情報が含まれている、[S3LogsConfig](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_S3LogsConfig.html) オブジェクト。
#### fileSystemLocations
オプション。Amazon EFS 設定に関する情報が含まれている、[ProjectFileSystemsLocation](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_ProjectFileSystemLocation.html) オブジェクトの配列。
#### buildBatchConfig
オプション。`buildBatchConfig` オブジェクトは [ProjectBuildBatchConfig](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_ProjectBuildBatchConfig.html) 構造体であり、プロジェクトのバッチビルド設定情報を含みます。
buildBatchConfig/**serviceRole**
バッチビルドプロジェクトのサービスロール ARN を指定します。
buildBatchConfig/**combineArtifacts**
バッチビルドのビルドアーティファクトを 1 つのアーティファクトの場所に結合するかどうかを指定するブール値。
buildBatchConfig/restrictions/**maximumBuildsAllowed**
許可されるビルドの最大数。
buildBatchConfig/restrictions/**computeTypesAllowed**
バッチビルドで許可されるコンピューティングタイプを指定する文字列の配列。これらの値については、「[ビルド環境のコンピューティングタイプ](https://docs.aws.amazon.com/codebuild/latest/userguide/build-env-ref-compute-types.html)」を参照してください。
buildBatchConfig/restrictions/**fleetsAllowed**
バッチビルドで許可されるフリートを指定する文字列の配列。詳細については、「[リザーブドキャパシティフリートでビルドを実行](https://docs.aws.amazon.com/codebuild/latest/userguide/fleets.html)」を参照してください。
buildBatchConfig/**timeoutInMinutes**
バッチビルドを完了するまでの最大時間 (分単位) 。
buildBatchConfig/**batchReportMode**
バッチビルドのソースプロバイダーにビルドステータスレポートを送信する方法を指定します。有効な値を次に示します。
`REPORT_AGGREGATED_BATCH`
(デフォルト) すべてのビルドステータスを 1 つのステータスレポートに集約します。
`REPORT_INDIVIDUAL_BUILDS`
個々のビルドごとに個別のステータスレポートを送信します。
#### concurrentBuildLimit
このジョブで許可される同時実行の最大数を設定します。
新しいビルドは、現在のビルド数がこの制限以下の場合にのみ開始されます。現在のビルドカウントがこの制限を満たす場合、新しいビルドはスロットルされ、実行されません。
### プロジェクトの作成
プロジェクトを作成するには、**[https://docs.aws.amazon.com/cli/latest/reference/codebuild/create-project.html](https://docs.aws.amazon.com/cli/latest/reference/codebuild/create-project.html)** コマンドを再度実行し、JSON ファイルを渡します。
```
aws codebuild create-project --cli-input-json file://
```
成功した場合、JSON 表現の [Project](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_Project.html) オブジェクトが、コンソール出力に表示されます。このデータの例については、「[CreateProject レスポンスの構文](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_CreateProject.html#API_CreateProject_ResponseSyntax)」を参照してください。
ビルドプロジェクトの名前を除いて、後でビルドプロジェクトの設定を変更することができます。詳細については、「[ビルドプロジェクトの設定の変更 (AWS CLI)](change-project.md#change-project-cli)」を参照してください。
ビルドの実行を開始するには、「[ビルドの実行 (AWS CLI)](run-build-cli.md)」を参照してください。
ソースコードが GitHub リポジトリに保存されていて、コード変更がリポジトリにプッシュされるたびに CodeBuild でソースコードを再構築する場合は、「[ビルドの実行の自動開始 (AWS CLI)](run-build-cli-auto-start.md)」を参照してください。
## ビルドプロジェクトの作成 (AWS SDK)
AWS CodeBuild を AWS SDK と組み合わせて使用する方法については、「[AWS SDKsとツールのリファレンス](sdk-ref.md)」を参照してください。
## ビルドプロジェクトの作成 (CloudFormation)
CloudFormation での AWS CodeBuild の使用については、*AWS CloudFormation ユーザーガイド*の「[CodeBuild の CloudFormation テンプレート](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-codebuild-project.html)」を参照してください。
# 通知ルールの作成
通知ルールを使用すると、ビルドの成功や失敗などの重要な変更が発生したときにユーザーに通知できます。通知ルールは、イベントと、通知の送信に使用される Amazon SNS トピックの両方を指定します。詳細については、「[通知とは](https://docs.aws.amazon.com/codestar-notifications/latest/userguide/welcome.html)」を参照してください。
コンソールまたは を使用して AWS CLI 、通知ルールを作成できます AWS CodeBuild。
# 通知ルールを作成するには (コンソール)
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/codebuild/](https://console.aws.amazon.com/codebuild/) で CodeBuild コンソールを開きます。
1. [**Build (ビルド)**]、[**Build projects (ビルドプロジェクト)**] の順に選択し、通知を追加するビルドプロジェクトを選択します。
1. ビルドプロジェクトページで、[**Notify (通知)**]、[**Create notification rule (通知ルールの作成)**] の順に選択します。ビルドプロジェクトの [**Settings (設定)**] ページに移動し、[**Create notification rule (通知ルールの作成)**] を選択することもできます。
1. [**通知名**] に、ルールの名前を入力します。
1. Amazon EventBridge に提供された情報のみを通知に含める場合は、**[Detail type (詳細タイプ)]** で **[Basic (基本)]** を選択します。Amazon EventBridge に提供される情報に加えて、CodeBuild または通知マネージャから提供される場合がある情報も含める場合は、**[完全]** を選択します。
詳細については、「[通知の内容とセキュリティについて](https://docs.aws.amazon.com/codestar-notifications/latest/userguide/security.html#security-notifications)」を参照してください。
1. [**Events that trigger notifications (通知をトリガーするイベント)**] で、通知を送信するイベントを選択します。詳細については、「[ビルドプロジェクトでの通知ルールのイベント](https://docs.aws.amazon.com/codestar-notifications/latest/userguide/concepts.html#events-ref-buildproject)」を参照してください。
1. [**Targets (ターゲット)**] で、次のいずれかの操作を行います。
+ 通知で使用するリソースを設定済みである場合は、**[ターゲットタイプを選択]** で、**[チャットアプリケーションの Amazon Q Developer (Slack)]** または **[SNS トピック]** を選択します。**[ターゲットを選択]** で、クライアントの名前 (チャットアプリケーションの Amazon Q Developer で設定した Slack クライアントの場合) または Amazon SNS トピックの Amazon リソースネーム (ARN) (通知に必要なポリシーが設定済みである Amazon SNS トピックの場合) を選択します。
+ 通知で使用するリソースを設定していない場合は、[**Create target**]、[**SNS topic**] の順に選択します。**codestar-notifications-** の後にトピックの名前を指定し、[**Create**] を選択します。
**注記**
通知ルールの作成の一環として Amazon SNS トピックを作成すると、トピックへのイベント発行を通知機能に許可するポリシーが適用されます。通知ルール用に作成したトピックを使用すると、このリソースに関する通知を受信するユーザーのみをサブスクライブできます。
通知ルールの作成の一環としてチャットアプリケーションの Amazon Q Developer クライアントを作成することはできません。チャットアプリケーションの Amazon Q Developer (Slack) を選択すると、チャットアプリケーションで Amazon Q Developer でクライアントを設定するように指示するボタンが表示されます。このオプションを選択すると、チャットアプリケーションの Amazon Q Developer コンソールが開きます。詳細については、[「通知とチャットアプリケーションの Amazon Q Developer との統合の設定](https://docs.aws.amazon.com/codestar-notifications/latest/userguide/notifications-chatbot.html)」を参照してください。
既存の Amazon SNS トピックをターゲットとして使用する場合は、このトピック用の他のすべてのポリシーに加えて、AWS CodeStar Notifications に必要なポリシーを追加する必要があります。詳細については、「[通知用の Amazon SNS トピックを設定する](https://docs.aws.amazon.com/codestar-notifications/latest/userguide/set-up-sns.html)」および「[通知の内容とセキュリティについて](https://docs.aws.amazon.com/codestar-notifications/latest/userguide/security.html#security-notifications)」を参照してください。
1. ルールの作成を終了するには、[**Submit (送信)**] を選択します。
1. 通知を受け取るには、そのルールの Amazon SNS トピックにユーザーをサブスクライブする必要があります。詳細については、「[ターゲットである Amazon SNS トピックへのユーザーのサブスクライブ](https://docs.aws.amazon.com/codestar-notifications/latest/userguide/subscribe-users-sns.html)」を参照してください。また、通知と Amazon Q Developer in chat applications を統合して、Amazon Chime チャットルームに通知を送信することもできます。詳細については、「[通知とチャットアプリケーションの Amazon Q Developer との統合の設定](https://docs.aws.amazon.com/codestar-notifications/latest/userguide/notifications-chatbot.html)」を参照してください。
# 通知ルールを作成するには (AWS CLI)
1. ターミナルまたはコマンドプロンプトで、**create-notification rule** コマンドを実行して、JSON スケルトンを生成します。
```
aws codestarnotifications create-notification-rule --generate-cli-skeleton > rule.json
```
ファイルには任意の名前を付けることができます。この例では、ファイルの名前を *rule.json* とします。
1. プレーンテキストエディタで JSON ファイルを開き、これを編集してルールに必要なリソース、イベントタイプ、ターゲットを含めます。次の例は、ID *123456789012* の AWS アカウントで *MyBuildProject* という名前のビルドプロジェクト**MyNotificationRule**に という名前の通知ルールを示しています。ビルドが成功したとき、通知は、完全な詳細タイプで Amazon SNS トピック *codestar-notifications-MyNotificationTopic* に送信されます：
```
{
"Name": "MyNotificationRule",
"EventTypeIds": [
"codebuild-project-build-state-succeeded"
],
"Resource": "arn:aws:codebuild:us-east-2:123456789012:MyBuildProject",
"Targets": [
{
"TargetType": "SNS",
"TargetAddress": "arn:aws:sns:us-east-2:123456789012:codestar-notifications-MyNotificationTopic"
}
],
"Status": "ENABLED",
"DetailType": "FULL"
}
```
ファイルを保存します。
1. 先ほど編集したファイルを使用して、ターミナルまたはコマンドラインで、**create-notification-rule** コマンドを再度実行し、通知ルールを作成します。
```
aws codestarnotifications create-notification-rule --cli-input-json file://rule.json
```
1. 成功すると、コマンドは次のような通知ルールの ARN を返します。
```
{
"Arn": "arn:aws:codestar-notifications:us-east-1:123456789012:notificationrule/dc82df7a-EXAMPLE"
}
```
# でビルドプロジェクト設定を変更する AWS CodeBuild
AWS CodeBuild コンソール、 AWS CLI、または AWS SDKs を使用して、ビルドプロジェクトの設定を変更できます。
ビルドプロジェクトにテストレポートを追加する場合は、[テストレポートのアクセス許可](test-permissions.md) で記載されている権限が IAM ロールに付与されていることを確認してください。
**Topics**
+ [
## ビルドプロジェクトの設定の変更 (コンソール)
](#change-project-console)
+ [
## ビルドプロジェクトの設定の変更 (AWS CLI)
](#change-project-cli)
+ [
## ビルドプロジェクトの設定を変更する (AWS SDKs)
](#change-project-sdks)
## ビルドプロジェクトの設定の変更 (コンソール)
ビルドプロジェクトの設定を変更するには、次の手順を実行します。
1. [https://console.aws.amazon.com/codesuite/codebuild/home](https://console.aws.amazon.com/codesuite/codebuild/home) で AWS CodeBuild コンソールを開きます。
1. ナビゲーションペインで、[**Build projects**] を選択します。
1. 次のいずれかを行ってください。
+ 変更するビルドプロジェクトのリンクを選択し、[**ビルドの詳細**] を選択します。
+ 変更するビルドプロジェクトの横にあるラジオボタンを選択して、[**View details (詳細を表示)**] を選択後 [**ビルドの詳細**] を選択します。
次のセクションを変更できます。
**Topics**
+ [
### プロジェクトの設定
](#change-project-console-project-config)
+ [
### ソース
](#change-project-console-source)
+ [
### 環境
](#change-project-console-environment)
+ [
### Buildspec
](#change-project-console-buildspec)
+ [
### Batch 構成
](#change-project-console-batch-config)
+ [
### アーティファクト
](#change-project-console-artifacts)
+ [
### ログ
](#change-project-console-logs)
### プロジェクトの設定
[**プロジェクトの設定**] セクションで、[**編集**] を選択します。変更が完了したら、[**設定の更新**] を選択して新しい設定を保存します。
次のプロパティを変更できます。
**説明**
また、他のユーザーがこのプロジェクトの使用目的を理解できるように、ビルドプロジェクトの説明を任意で指定することもできます。
**ビルドバッジ**
[**Enable build badge (ビルドバッジを有効にする)**] を選択すると、プロジェクトのビルドステータスが表示可能および埋め込み可能になります。詳細については、「[ビルドバッジサンプル](sample-build-badges.md)」を参照してください。
ソースプロバイダーが Amazon S3 の場合、ビルドバッジは適用されません。
**同時ビルド制限を有効にする**
このプロジェクトで同時ビルド数を制限するには、次の手順を実行します。
1. **[Restrict number of concurrent builds this project can start]** (このジョブで許可される同時実行の最大数を設定) を選択します。
1. **[Concurrent build limit]** (同時ビルド制限) で、このジョブで許可される同時実行の最大数を設定します。この制限は、アカウントに設定された同時ビルド制限より大きくすることはできません。アカウント制限を超える数値を入力しようとすると、エラーメッセージが表示されます。
新しいビルドは、現在のビルド数がこの制限以下の場合にのみ開始されます。現在のビルドカウントがこの制限を満たす場合、新しいビルドはスロットルされ、実行されません。
**パブリックビルドアクセスを有効にする**
AWS アカウントにアクセスできないユーザーを含め、プロジェクトのビルド結果を一般公開するには、**パブリックビルドアクセスを有効にする**を選択し、ビルド結果を公開することを確認します。パブリックビルドプロジェクトでは、次のプロパティが使用されます。
**パブリックビルドのサービスロール**
CodeBuild で新しいサービスロールを作成する場合は [**New service role**] (新しいサービスロール) を、既存のサービスロールを使用する場合は [**Existing service role**] (既存のサービスロール) を選択します。
パブリックビルドのサービスロールを使用することにより、CodeBuild で CloudWatch Logs を読み取り、プロジェクトのビルド用の Amazon S3 アーティファクトをダウンロードできます。これは、プロジェクトのビルドログとアーティファクトを一般に公開するために必要です。
**サービスロール**
新しいサービスロールまたは既存のサービスロールの名前を入力します。
プロジェクトのビルド結果をプライベートにするには、[**Enable public build access**] (パブリックビルドアクセスを有効にする) のチェックを外します。
詳細については、「[パブリックビルドプロジェクトの URL を取得](public-builds.md)」を参照してください。
プロジェクトのビルド結果を一般に公開する際には、以下に留意してください。
+ プロジェクトがプライベートだったときに実行されたビルドも含めて、プロジェクトのビルド結果、ログ、アーティファクトはすべて、一般に公開されます。
+ すべてのビルドログとアーティファクトが一般に公開されます。環境変数、ソースコード、およびその他の機密情報がビルドログとアーティファクトに出力されている可能性があります。ビルドログに出力される情報には注意が必要です。以下にベストプラクティスを示します。
+ 機密値、特に AWS アクセスキー IDsとシークレットアクセスキーを環境変数に保存しないでください。機密値 AWS Secrets Manager を保存するには、Amazon EC2 Systems Manager パラメータストアまたは を使用することをお勧めします。
+ [ウェブフック使用のベストプラクティス。](webhooks.md#webhook-best-practices) に従って、ビルドをトリガーできるエンティティを制限し、buildspec をプロジェクト自体に保存しないことで、Webhook を可能な限り安全に保つことができます。
+ 悪意のあるユーザーがパブリックビルドを利用して、悪意のあるアーティファクトを配信する可能性があります。プロジェクト管理者は、すべてのプルリクエストを確認し、プルリクエストが正当な変更であるか検証することをお勧めします。また、チェックサムを使ってすべてのアーティファクトを検証し、正しいアーティファクトがダウンロードされているか確認することを推奨します。
**追加情報**
**タグ**には、サポート AWS サービスで使用するタグの名前と値を入力します。[**Add row**] を使用して、タグを追加します。最大 50 個のタグを追加できます。
### ソース
[**ソース**] セクションで [**編集**] を選択します。変更が完了したら、[**設定の更新**] を選択して新しい設定を保存します。
次のプロパティを変更できます。
**ソースプロバイダー**
ソースコードプロバイダーのタイプを選択します。次のリストを使用して、ソースプロバイダーに関する適切な選択を行います。
CodeBuild は Bitbucket サーバーをサポートしていません。
------
#### [ Amazon S3 ]
**バケット**
ソースコードが格納されている入力バケットの名前を選択します。
**S3 オブジェクトキーまたは S3 フォルダ**
ZIP ファイルの名前、またはソースコードを含むフォルダへのパスを入力します。S3 バケットの中身をすべてダウンロードするには、スラッシュ記号 (/) を入力します。
**ソースバージョン**
入力ファイルのビルドを表すオブジェクトのバージョン IDを入力。詳細については、「[を使用したソースバージョンサンプル AWS CodeBuild](sample-source-version.md)」を参照してください。
------
#### [ CodeCommit ]
**リポジトリ**
使用するリポジトリを選択します。
**参照タイプ**
**[Branch] **(ブランチ) または** [Git tag]** (Git タグ) を選択するか、**[Commit ID]** (コミット ID) を入力して、ソースコードのバージョンを指定します。詳細については、「[を使用したソースバージョンサンプル AWS CodeBuild](sample-source-version.md)」を参照してください。
`811dd1ba1aba14473856cee38308caed7190c0d` または `5392f7` のように、コミット ID と似ていない Git ブランチ名を選択することをお勧めします。これにより、Git checkout が実際のコミットと衝突するのを防ぐことができます。
**Git クローンの深度**
選択して、指定されるコミット数で切り捨てられる履歴の浅いクローンを作成します。完全クローンを希望する場合には、[**Full (完全)**] を選択します。
**Git サブモジュール**
リポジトリに Git サブモジュールを含める場合は、[**Git サブモジュールを使用する**] を選択します。
------
#### [ Bitbucket ]
**[認証情報]**
**[デフォルトソース認証情報]** または **[カスタムソース認証情報]** を選択し、手順に従ってデフォルトソース認証情報を管理するか、ソース認証情報をカスタマイズします。
**[接続タイプ]**
**[CodeConnections]**、**[OAuth]**、**[アプリパスワード]**、または **[個人用アクセストークン]** を選択して CodeBuild に接続します。
**Connection**
Bitbucket 接続または Secrets Manager シークレットを選択して、指定した接続タイプ経由で接続します。
**リポジトリ**
**[Bitbucket アカウントのリポジトリ]** または **[パブリックリポジトリ]** を選択し、リポジトリ URL を入力します。
**ソースバージョン**
ブランチ、コミット ID、タグあるいはリファレンスとコミット ID を入力します。詳細については、「[を使用したソースバージョンサンプル AWS CodeBuild](sample-source-version.md)」を参照してください。
`811dd1ba1aba14473856cee38308caed7190c0d` または `5392f7` のように、コミット ID と似ていない Git ブランチ名を選択することをお勧めします。これにより、Git checkout が実際のコミットと衝突するのを防ぐことができます。
**Git クローンの深度**
[**Git のクローンの深さ**] を選択して、指定されるコミット数で切り捨てられる履歴の浅いクローンを作成します。完全クローンを希望する場合には、[**Full (完全)**] を選択します。
**Git サブモジュール**
リポジトリに Git サブモジュールを含める場合は、[**Git サブモジュールを使用する**] を選択します。
**ビルドステータス**
ビルドの開始と終了のステータスをソースプロバイダーにレポートする場合は、**[Report build statuses to source provider when your builds start and finish]** (ビルドの開始と終了時にソースプロバイダーにビルドステータスをレポートする) を選択します。
ソースプロバイダにビルド状態を報告できるようにするには、ソースプロバイダに関連付けられたユーザーがリポジトリへの書き込みアクセス権を持っている必要があります。ユーザーが書き込みアクセス権を持っていない場合、ビルドのステータスは更新できません。詳細については、「[ソースプロバイダーのアクセス](access-tokens.md)」を参照してください。
**[Status context]** (ステータスコンテキスト) に、Bitbucket コミットステータスの `name` パラメータに使用する値を記入します。詳細については、Bitbucket API ドキュメントの「[ビルド](https://developer.atlassian.com/bitbucket/api/2/reference/resource/repositories/%7Bworkspace%7D/%7Brepo_slug%7D/commit/%7Bnode%7D/statuses/build)」を参照してください。
**[Target URL]** (ターゲットURL) に、Bitbucket コミットステータスの `url` パラメータに使用する値を記入します。詳細については、Bitbucket API ドキュメントの「[ビルド](https://developer.atlassian.com/bitbucket/api/2/reference/resource/repositories/%7Bworkspace%7D/%7Brepo_slug%7D/commit/%7Bnode%7D/statuses/build)」を参照してください。
webhook によってトリガーされたビルドのステータスは常にソースプロバイダーにレポートされます。コンソールから開始されたビルドのステータスまたはソースプロバイダーに報告された API 呼び出しを取得するには、この設定を選択する必要があります。
プロジェクトのビルドが webhook によってトリガーされた場合、この設定への変更を有効にするには、新しいコミットをリポジトリにプッシュする必要があります。
[**Primary source webhook events**] (プライマリソース Webhook イベント) で [**Rebuild every time a code change is pushed to this repository**] (コード変更がこのリポジトリにプッシュされるたび再構築) を選択して、コード変更がこのリポジトリにプッシュされるたびに CodeBuild で再構築します。Webhook およびフィルターグループの詳細については、「[Bitbucket ウェブフックイベント](bitbucket-webhook.md)」を参照してください。
------
#### [ GitHub ]
**[認証情報]**
**[デフォルトソース認証情報]** または **[カスタムソース認証情報]** を選択し、手順に従ってデフォルトソース認証情報を管理するか、ソース認証情報をカスタマイズします。
**[接続タイプ]**
**[GitHub アプリ]**、**[OAuth]**、または **[個人用アクセストークン]** を選択して CodeBuild に接続します。
**Connection**
GitHub 接続または Secrets Manager シークレットを選択して、指定した接続タイプ経由で接続します。
**リポジトリ**
**[GitHub アカウントのリポジトリ]**、**[パブリックリポジトリ]**、または **[GitHub スコープ付きウェブフック]** を選択し、リポジトリ URL を入力します。
**ソースバージョン**
ブランチ、コミット ID、タグあるいはリファレンスとコミット ID を入力します。詳細については、「[を使用したソースバージョンサンプル AWS CodeBuild](sample-source-version.md)」を参照してください。
`811dd1ba1aba14473856cee38308caed7190c0d` または `5392f7` のように、コミット ID と似ていない Git ブランチ名を選択することをお勧めします。これにより、Git checkout が実際のコミットと衝突するのを防ぐことができます。
**Git クローンの深度**
[**Git のクローンの深さ**] を選択して、指定されるコミット数で切り捨てられる履歴の浅いクローンを作成します。完全クローンを希望する場合には、[**Full (完全)**] を選択します。
**Git サブモジュール**
リポジトリに Git サブモジュールを含める場合は、[**Git サブモジュールを使用する**] を選択します。
**ビルドステータス**
ビルドの開始と終了のステータスをソースプロバイダーにレポートする場合は、**[Report build statuses to source provider when your builds start and finish]** (ビルドの開始と終了時にソースプロバイダーにビルドステータスをレポートする) を選択します。
ソースプロバイダにビルド状態を報告できるようにするには、ソースプロバイダに関連付けられたユーザーがリポジトリへの書き込みアクセス権を持っている必要があります。ユーザーが書き込みアクセス権を持っていない場合、ビルドのステータスは更新できません。詳細については、「[ソースプロバイダーのアクセス](access-tokens.md)」を参照してください。
**[Status context]** (ステータスコンテキスト) に、GitHub コミットステータスの `context`パラメータに使用する値を記入します。ｑ 詳細については、GitHub デベロッパーガイドの「[コミットステータスの作成](https://developer.github.com/v3/repos/statuses/#create-a-commit-status)」を参照してください。
**[Target URL] **(ターゲット URL) に、 GitHub コミットステータスの `target_url` パラメータに使用する値を記入します。詳細については、GitHub デベロッパーガイドの「[コミットステータスの作成](https://developer.github.com/v3/repos/statuses/#create-a-commit-status)」を参照してください。
webhook によってトリガーされたビルドのステータスは、常にソースプロバイダーにレポートされます。コンソールから開始されたビルドのステータスまたはソースプロバイダーに報告された API 呼び出しを取得するには、この設定を選択する必要があります。
プロジェクトのビルドが webhook によってトリガーされた場合、この設定への変更を有効にするには、新しいコミットをリポジトリにプッシュする必要があります。
[**Primary source webhook events**] (プライマリソース Webhook イベント) で [**Rebuild every time a code change is pushed to this repository**] (コード変更がこのリポジトリにプッシュされるたび再構築) を選択して、コード変更がこのリポジトリにプッシュされるたびに CodeBuild で再構築します。Webhook およびフィルターグループの詳細については、「[GitHub ウェブフックイベント](github-webhook.md)」を参照してください。
------
#### [ GitHub Enterprise Server ]
**[認証情報]**
**[デフォルトソース認証情報]** または **[カスタムソース認証情報]** を選択し、手順に従ってデフォルトソース認証情報を管理するか、ソース認証情報をカスタマイズします。
**[接続タイプ]**
**[CodeConnections]** または **[個人用アクセストークン]** を選択して CodeBuild に接続します。
**Connection**
GitHub Enterprise 接続または Secrets Manager シークレットを選択して、指定した接続タイプ経由で接続します。
**リポジトリ**
**[自分の GitHub Enterprise アカウントのレポジトリ]** または **[GitHub Enterprise スコープ付きウェブフック]** を選択し、リポジトリ URL を入力します。
**ソースバージョン**
プルリクエスト、ブランチ、コミット ID、コミット ID、参照、およびコミット ID を入力します。詳細については、「[を使用したソースバージョンサンプル AWS CodeBuild](sample-source-version.md)」を参照してください。
`811dd1ba1aba14473856cee38308caed7190c0d` または `5392f7` のように、コミット ID と似ていない Git ブランチ名を選択することをお勧めします。これにより、Git checkout が実際のコミットと衝突するのを防ぐことができます。
**Git クローンの深度**
[**Git のクローンの深さ**] を選択して、指定されるコミット数で切り捨てられる履歴の浅いクローンを作成します。完全クローンを希望する場合には、[**Full (完全)**] を選択します。
**Git サブモジュール**
リポジトリに Git サブモジュールを含める場合は、[**Git サブモジュールを使用する**] を選択します。
**ビルドステータス**
ビルドの開始と終了のステータスをソースプロバイダーにレポートする場合は、**[Report build statuses to source provider when your builds start and finish]** (ビルドの開始と終了時にソースプロバイダーにビルドステータスをレポートする) を選択します。
ソースプロバイダにビルド状態を報告できるようにするには、ソースプロバイダに関連付けられたユーザーがリポジトリへの書き込みアクセス権を持っている必要があります。ユーザーが書き込みアクセス権を持っていない場合、ビルドのステータスは更新できません。詳細については、「[ソースプロバイダーのアクセス](access-tokens.md)」を参照してください。
**[Status context]** (ステータスコンテキスト) に、GitHub コミットステータスの `context`パラメータに使用する値を記入します。ｑ 詳細については、GitHub デベロッパーガイドの「[コミットステータスの作成](https://developer.github.com/v3/repos/statuses/#create-a-commit-status)」を参照してください。
**[Target URL] **(ターゲット URL) に、 GitHub コミットステータスの `target_url` パラメータに使用する値を記入します。詳細については、GitHub デベロッパーガイドの「[コミットステータスの作成](https://developer.github.com/v3/repos/statuses/#create-a-commit-status)」を参照してください。
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 ウェブフックイベント](github-webhook.md)」を参照してください。
------
#### [ GitLab ]
**[認証情報]**
**[デフォルトソース認証情報]** または **[カスタムソース認証情報]** を選択し、手順に従ってデフォルトソース認証情報を管理するか、ソース認証情報をカスタマイズします。
**[接続タイプ]**
**[CodeConnections]** は、GitLab を CodeBuild に接続するために使用されます。
**Connection**
CodeConnections 経由で接続する GitLab 接続を選択します。
**リポジトリ**
使用するリポジトリを選択します。
**ソースバージョン**
プルリクエスト ID、ブランチ、コミット ID、タグ、または参照およびコミット ID を入力します。詳細については、「[を使用したソースバージョンサンプル AWS CodeBuild](sample-source-version.md)」を参照してください。
`811dd1ba1aba14473856cee38308caed7190c0d` または `5392f7` のように、コミット ID と似ていない Git ブランチ名を選択することをお勧めします。これにより、Git checkout が実際のコミットと衝突するのを防ぐことができます。
**Git クローンの深度**
[**Git のクローンの深さ**] を選択して、指定されるコミット数で切り捨てられる履歴の浅いクローンを作成します。完全クローンを希望する場合には、[**Full (完全)**] を選択します。
**ビルドステータス**
ビルドの開始と終了のステータスをソースプロバイダーにレポートする場合は、**[Report build statuses to source provider when your builds start and finish]** (ビルドの開始と終了時にソースプロバイダーにビルドステータスをレポートする) を選択します。
ソースプロバイダにビルド状態を報告できるようにするには、ソースプロバイダに関連付けられたユーザーがリポジトリへの書き込みアクセス権を持っている必要があります。ユーザーが書き込みアクセス権を持っていない場合、ビルドのステータスは更新できません。詳細については、「[ソースプロバイダーのアクセス](access-tokens.md)」を参照してください。
------
#### [ GitLab Self Managed ]
**[認証情報]**
**[デフォルトソース認証情報]** または **[カスタムソース認証情報]** を選択し、手順に従ってデフォルトソース認証情報を管理するか、ソース認証情報をカスタマイズします。
**[接続タイプ]**
**[CodeConnections]** は、GitLab セルフマネージドを CodeBuild に接続するために使用されます。
**Connection**
CodeConnections 経由で接続する GitLab セルフマネージド接続を選択します。
**リポジトリ**
使用するリポジトリを選択します。
**ソースバージョン**
プルリクエスト ID、ブランチ、コミット ID、タグ、または参照およびコミット ID を入力します。詳細については、「[を使用したソースバージョンサンプル AWS CodeBuild](sample-source-version.md)」を参照してください。
`811dd1ba1aba14473856cee38308caed7190c0d` または `5392f7` のように、コミット ID と似ていない Git ブランチ名を選択することをお勧めします。これにより、Git checkout が実際のコミットと衝突するのを防ぐことができます。
**Git クローンの深度**
[**Git のクローンの深さ**] を選択して、指定されるコミット数で切り捨てられる履歴の浅いクローンを作成します。完全クローンを希望する場合には、[**Full (完全)**] を選択します。
**ビルドステータス**
ビルドの開始と終了のステータスをソースプロバイダーにレポートする場合は、**[Report build statuses to source provider when your builds start and finish]** (ビルドの開始と終了時にソースプロバイダーにビルドステータスをレポートする) を選択します。
ソースプロバイダにビルド状態を報告できるようにするには、ソースプロバイダに関連付けられたユーザーがリポジトリへの書き込みアクセス権を持っている必要があります。ユーザーが書き込みアクセス権を持っていない場合、ビルドのステータスは更新できません。詳細については、「[ソースプロバイダーのアクセス](access-tokens.md)」を参照してください。
------
### 環境
[**環境**] セクションで、[**編集**] を選択します。変更が完了したら、[**設定の更新**] を選択して新しい設定を保存します。
次のプロパティを変更できます。
**[プロビジョニングモデル]**
プロビジョニングモデルを変更するには、**[プロビジョニングモデルを変更]** を選択し、次のいずれかを実行します。
+ が管理するオンデマンドフリートを使用するには AWS CodeBuild、**オンデマンド**を選択します。オンデマンドフリートでは、CodeBuild がビルドのコンピューティングを行います。マシンはビルドが終了すると破棄されます。オンデマンドフリートはフルマネージド型で、需要の急増にも対応できる自動スケーリング機能を備えています。
+ が管理するリザーブドキャパシティフリートを使用するには AWS CodeBuild、**リザーブドキャパシティ**を選択し、**フリート名**を選択します。リザーブドキャパシティフリートでは、ビルド環境に合わせて専有インスタンスのセットを設定します。これらのマシンはアイドル状態のままで、ビルドやテストをすぐに処理できる状態になり、ビルド時間を短縮します。リザーブドキャパシティフリートでは、マシンは常に稼働しており、プロビジョニングされている間はコストが発生し続けます。
詳細については、「[リザーブドキャパシティキャパシティフリートでビルドを実行](fleets.md)」を参照してください。
**環境イメージ**
ビルドイメージを変更するには、[**イメージの上書き**] を選択し、次のいずれかを実行します。
+ が管理する Docker イメージを使用するには AWS CodeBuild、**マネージドイメージ**を選択し、**オペレーティングシステム**、**ランタイム (複数可)**、**イメージ**、**イメージバージョン**から選択します。利用可能な場合は、[**環境タイプ**] から選択します。
+ 別の 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 とは](https://docs.aws.amazon.com/secretsmanager/latest/userguide/)」を参照してください。
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](https://docs.docker.com/engine/reference/run/#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 で を使用する](vpc-support.md)」を参照してください。
**コンピューティング**
使用可能なオプションの 1 つを選択します。
**レジストリ認証情報**
プロジェクトが非プライベートレジストリイメージで設定されている場合は、レジストリ認証情報を指定します。
この認証情報は、イメージがプライベートレジストリのイメージで上書きされている場合にのみ使用されます。
**環境変数**
[環境変数] で、名前と値を入力してから、ビルドによって使用される各環境変数の種類を選択します。
CodeBuild は、 AWS リージョンの環境変数を自動的に設定します。以下の環境変数を buildspec.yml に追加していない場合は、それらの変数を設定する必要があります。
+ AWS\$1ACCOUNT\$1ID
+ IMAGE\$1REPO\$1NAME
+ IMAGE\$1TAG
コンソールと AWS CLI ユーザーは環境変数を表示できます。環境変数の表示に懸念がない場合は、[**Name**] および [**Value**] フィールドを設定し、[**Type**] を [**Plaintext**] に設定します。
アクセスキー ID、 AWS シークレット AWS アクセスキー、パスワードなどの機密性の高い値を持つ環境変数をパラメータとして Amazon EC2 Systems Manager パラメータストアまたは に保存することをお勧めします AWS Secrets Manager。
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 パラメータストア](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)」を参照してください。
ビルドプロジェクトが 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 reference-key in the buildspec file](build-spec-ref.md#secrets-manager-build-spec)」を参照してください。
Secrets Manager を使用する場合は、「`/CodeBuild/`」で始まる名前でシークレットを保存することをお勧めします(たとえば、`/CodeBuild/dockerLoginPassword`)。詳細については、* AWS Secrets Managerユーザーガイド*の「[AWS Secrets Manager とは](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html)」を参照してください。
ビルドプロジェクトが 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:::/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) に関するリファレンス](build-spec-ref.md)」を参照してください。
### Batch 構成
[**バッチ構成**] セクションで、[**編集**] を選択します。変更が完了したら、[**設定の更新**] を選択して新しい設定を保存します。詳細については、「[ビルドをバッチで実行](batch-build.md)」を参照してください。
次のプロパティを変更できます。
**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 の構文](build-spec-ref.md#build-spec-ref-syntax)」を参照してください。
+ [**Bucket name (バケット名)**] で、出力バケットの名前を選択します。
+ この手順の前の方で [**ビルドコマンドの挿入**] を選択した場合は、[**出力ファイル**] に、ビルド出力 ZIP ファイルまたはフォルダに格納するビルドのファイルの場所を入力します。複数の場所の場合は、各場所をコンマで区切ります (例: `appspec.yml, target/my-app.jar`)。詳細については、「`files`」で [buildspec の構文](build-spec-ref.md#build-spec-ref-syntax) の説明を参照してください。
+ ビルドアーティファクトを暗号化しない場合は、[**アーティファクト暗号化の削除**] を選択します。
アーティファクトのセカンダリセットごとに:
1. [**Artifact 識別子**] には、英数字とアンダースコアのみを使用して 128 文字未満の値を入力します。
1. [**アーティファクトの追加**] を選択します。
1. セカンダリアーティファクトを設定するには、前のステップに従います。
1. [**アーティファクトの保存**] を選択します。
**追加設定**
**暗号化キー**
次のいずれかを行います。
+ アカウントで 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 の構文](build-spec-ref.md#build-spec-ref-syntax)」を参照してください。キャッシングの詳細については、「[パフォーマンスを向上させるためのキャッシュビルド](build-caching.md)」を参照してください。
### ログ
[**ログ**] セクションで [**編集**] を選択します。変更が完了したら、[**設定の更新**] を選択して新しい設定を保存します。
次のプロパティを変更できます。
作成するログを選択します。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、「」を参照してください[コマンドラインリファレンス](cmd-ref.md)。
で CodeBuild プロジェクトを更新するには AWS CLI、更新されたプロパティを含む JSON ファイルを作成し、そのファイルを [https://docs.aws.amazon.com/cli/latest/reference/codebuild/update-project.html](https://docs.aws.amazon.com/cli/latest/reference/codebuild/update-project.html) コマンドに渡します。更新ファイルに含まれていないプロパティは変更されません。
更新 JSON ファイルでは、`name` プロパティおよび変更されたプロパティのみが必要です。`name` プロパティにより、変更するプロジェクトを識別します。変更された構造については、それらの構造に必要なパラメータも含める必要があります。たとえば、プロジェクトの環境を変更するには、「`environment/type`」および「`environment/computeType`」プロパティが必要です。環境イメージを更新する例を次に示します。
```
{
"name": "",
"environment": {
"type": "LINUX_CONTAINER",
"computeType": "BUILD_GENERAL1_SMALL",
"image": "aws/codebuild/amazonlinux-x86_64-standard:4.0"
}
}
```
プロジェクトの現在のプロパティ値を取得する必要がある場合は、[https://docs.aws.amazon.com/cli/latest/reference/codebuild/batch-get-projects.html](https://docs.aws.amazon.com/cli/latest/reference/codebuild/batch-get-projects.html) コマンドを使用して、変更するプロジェクトの現在のプロパティを取得し、出力をファイルに書き込みます。
```
aws codebuild batch-get-projects --names "" > project-info.json
```
*project-info.json* ファイルには、プロジェクトの配列が含まれているため、プロジェクトを更新するために直接使用することはできません。ただし、変更したいプロパティを *project-info.json* ファイルからコピーして更新ファイル内に貼り付け、変更するプロパティのベースラインとすることができます。詳細については、「[ビルドプロジェクトの詳細を表示する (AWS CLI)](view-project-details.md#view-project-details-cli)」を参照してください。
「[ビルドプロジェクトの作成 (AWS CLI)](create-project.md#create-project-cli)」の説明に従って、更新 JSON ファイルを変更し、結果を保存します。更新 JSON ファイルの変更が完了したら、[https://docs.aws.amazon.com/cli/latest/reference/codebuild/update-project.html](https://docs.aws.amazon.com/cli/latest/reference/codebuild/update-project.html) コマンドを実行し、更新 JSON ファイルを渡します。
```
aws codebuild update-project --cli-input-json 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 SDKs)
SDK AWS CodeBuild で を使用する方法については、「」を参照してください[AWS SDKsとツールのリファレンス](sdk-ref.md)。 AWS SDKs
# CodeBuild の複数のアクセストークン
CodeBuild は、 内 AWS Secrets Manager または AWS CodeConnections 接続を介したシークレットからサードパーティープロバイダーへのアクセストークンの調達をサポートしています。シークレットまたは接続は、GitHub、GitHub Enterprise、Bitbucket などの指定されたサードパーティープロバイダとのやり取りのデフォルトの認証情報として設定できます。
ソース認証情報は、次の 3 つの異なるレベルで設定できます。
1. **すべてのプロジェクトのアカウントレベルの認証情報:** これらは、 AWS アカウント内のすべてのプロジェクトのデフォルトの認証情報です。プロジェクトまたはソースレベルの認証情報が指定されていない場合、プロジェクトで使用されます。
1. **特定のリポジトリのソースレベルの認証情報:** これは、プロジェクトソースで Secrets Manager シークレットまたは CodeConnections 接続が定義されている場合です。これらの認証情報は、指定されたソースリポジトリでのオペレーションにのみ使用されます。これにより、同じプロジェクトで異なるアクセス許可スコープを持つ複数のアクセストークンを設定でき、デフォルトのアカウントレベルの認証情報を使用しないようにすることができます。
1. **プロジェクトレベルのフォールバック認証情報:** プライマリソースタイプとして `NO_SOURCE` を使用してプロジェクトレベルのフォールバック認証情報を設定し、それにシークレットまたは接続を定義できます。これは、プロジェクトに複数のソースがあるものの、同じ認証情報をそれらのソースに使用する場合、またはプロジェクトのデフォルトのアカウントレベルの認証情報を使用しない場合に使用できます。
**Topics**
+ [
## ステップ 1: Secrets Manager シークレットまたは CodeConnections 接続を作成
](#create-secret-connection)
+ [
## ステップ 2: CodeBuild プロジェクトの IAM ロールに Secrets Manager シークレットへのアクセスを許可
](#asm-role-access)
+ [
## ステップ 3: Secrets Manager または CodeConnections トークンを設定
](#asm-account-credential)
+ [
## 追加のセットアップオプション
](#asm-credential-cfn)
## ステップ 1: Secrets Manager シークレットまたは CodeConnections 接続を作成
Secrets Manager シークレットまたは CodeConnections 接続を作成するには、次の手順に従います。
+ [Secrets Manager シークレットにトークンを作成して保存](asm-create-secret.md).
+ [GitHub への接続を作成](https://docs.aws.amazon.com/dtconsole/latest/userguide/connections-create-github.html)
+ [GitHub Enterprise Server への接続を作成](https://docs.aws.amazon.com/dtconsole/latest/userguide/connections-create-gheserver.html)
+ [Bitbucket への接続を作成](https://docs.aws.amazon.com/dtconsole/latest/userguide/connections-create-bitbucket.html)
## ステップ 2: CodeBuild プロジェクトの IAM ロールに Secrets Manager シークレットへのアクセスを許可
**注記**
続行する前に、Secrets Manager または CodeConnections で作成されたトークンにアクセスできるようにしておく必要があります。
CodeBuild プロジェクトの IAM ロールに Secrets Manager または CodeConnections へのアクセスを許可するには、次の IAM ポリシーを追加する必要があります。
**CodeBuild プロジェクトの IAM ロールにアクセスを許可するには**
1. CodeBuild プロジェクトの [CodeBuild が他の AWS サービスとやり取りすることを許可する](setting-up-service-role.md) の手順に従って、CodeBuild プロジェクトの IAM ロールを作成します。
1. 次のいずれかを行います。
+ CodeBuild プロジェクトロールに次の IAM ポリシーを追加して、シークレットへのアクセスを許可します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"secretsmanager:GetSecretValue"
],
"Resource": [
"arn:aws:iam::*:role/Service*"
]
}
]
}
```
------
(オプション) AWS KMS カスタマーマネージドキーを使用して Secrets Manager シークレットを暗号化する場合は、次のポリシーステートメントを追加してアクセスを許可できます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kms:Decrypt"
],
"Resource": "arn:aws:iam::*:role/Service*",
"Condition": {
"StringEquals": {
"kms:EncryptionContext:SecretARN": "arn:aws:iam::*:role/Service*"
}
}
}
]
}
```
------
+ CodeBuild プロジェクトロールに次の IAM ポリシーを追加して、接続へのアクセスを許可します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"codeconnections:GetConnectionToken",
"codeconnections:GetConnection"
],
"Resource": [
"arn:aws:iam::*:role/Service*"
]
}
]
}
```
------
## ステップ 3: Secrets Manager または CodeConnections トークンを設定
Secrets Manager トークンまたは CodeConnections トークンを使用して、ソース認証情報を 3 つの異なるレベルで設定できます。
### Secrets Manager または CodeConnections トークンをアカウントレベルの認証情報として設定
Secrets Manager シークレットまたは CodeConnections 接続をアカウントレベルの認証情報として設定し、プロジェクトで使用できます。
------
#### [ AWS マネジメントコンソール ]
**でアカウントレベルの認証情報として接続を設定するには AWS マネジメントコンソール**
1. **[ソースプロバイダ]** には、**[Bitbucket]**、**[GitHub]**、または **[GitHub Enterprise]** を選択します。
1. **[認証情報]** で、次のいずれかを実行します。
+ **[デフォルトソース認証情報]** を選択し、アカウントのデフォルトソース認証情報を使用して、すべてのプロジェクトに適用します。
1. ソースプロバイダに接続していない場合は、**[デフォルトソース認証情報を管理]** を選択します。
1. **[認証情報タイプ]** では、認証情報タイプを選択します。
1. **[CodeConnections]** を選択した場合は、既存の接続を使用するか、新しい接続を作成することを選択します。
別の認証情報タイプを選択した場合は、**[サービス]** でトークンの保存に使用するサービスを選択し、以下を実行します。
+ **[Secrets Manager]** を使用することを選択した場合は、既存のシークレット接続を使用するか、新しいシークレットを作成して **[保存]** を選択できます。新しいシークレットの作成方法の詳細については、「[Secrets Manager シークレットにトークンを作成して保存](asm-create-secret.md)」を参照してください。
+ **[CodeBuild]** を使用することを選択した場合は、トークンまたはユーザー名とアプリパスワードを入力し、**[保存]** を選択します。
+ **[カスタムソース認証情報]** を選択し、カスタムソース認証情報を使用してアカウントのデフォルト設定を上書きします。
1. **[認証情報タイプ]** では、認証情報タイプを選択します。
1. **[接続]** で、既存の接続を使用するか、新規の接続を作成することを選択します。
------
#### [ AWS CLI ]
**でアカウントレベルの認証情報として接続を設定するには AWS CLI**
+ ターミナル (Linux/macOS/Unix) またはコマンドプロンプト (Windows) を開きます。 AWS CLI を使用して **import-source-credentials** コマンドを実行します。
次のコマンドを使用して Secrets Manager のシークレットを設定します。
```
aws codebuild import-source-credentials \
--token "" \
--server-type \
--auth-type SECRETS_MANAGER \
--region
```
次のコマンドを使用して CodeConnections 接続を設定します。
```
aws codebuild import-source-credentials \
--token "" \
--server-type \
--auth-type CODECONNECTIONS \
--region
```
このコマンドを使用すると、アカウントレベルのデフォルトソース認証情報としてトークンをインポートできます。[ImportSourceCredentials](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_ImportSourceCredentials.html) API を使用して認証情報をインポートする場合、CodeBuild は、より具体的な認証情報のセットがプロジェクトで設定されていない限り、ウェブフック、ビルドステータスレポート、git clone オペレーションなど、ソースプロバイダとのすべてのやり取りにそのトークンを使用します。
------
これで、ビルドプロジェクトでトークンを使用して実行できるようになりました。詳細については、「[でのビルドプロジェクトの作成AWS CodeBuild](create-project.md)」および「[AWS CodeBuild ビルドを手動で実行する](run-build.md)」を参照してください。
### 複数のトークンをソースレベルの認証情報として設定
Secrets Manager シークレットまたは CodeConnections 接続をソースレベルの認証情報として使用するには、CodeBuild プロジェクトのトークンを直接参照し、ビルドを開始します。
------
#### [ AWS マネジメントコンソール ]
**でソースレベルの認証情報として複数のトークンを設定するには AWS マネジメントコンソール**
1. [**ソースプロバイダー**] で [**GitHub**] を選択します。
1. **[認証情報]** で、次のいずれかを実行します。
+ **[デフォルトソース認証情報]** を選択し、アカウントのデフォルトソース認証情報を使用して、すべてのプロジェクトに適用します。
1. GitHub に接続していない場合は、**[デフォルトソース認証情報を管理]** を選択します。
1. **[認証情報タイプ]** では、**[GitHub アプリ]** を選択します。
1. **[接続]** で、既存の接続を使用するか、新規の接続を作成することを選択します。
+ **[カスタムソース認証情報]** を選択し、カスタムソース認証情報を使用してアカウントのデフォルト設定を上書きします。
1. **[認証情報タイプ]** では、**[GitHub アプリ]** を選択します。
1. **[接続]** で、既存の接続を使用するか、新規の接続を作成することを選択します。
1. **[ソースを追加]** を選択し、ソースプロバイダと認証情報を選択するプロセスを繰り返します。
------
#### [ AWS CLI ]
**でソースレベルの認証情報として複数のトークンを設定するには AWS CLI**
+ ターミナル (Linux/macOS/Unix) またはコマンドプロンプト (Windows) を開きます。 AWS CLI を使用して **create-project** コマンドを実行します。
以下のコマンドを使用します。
```
aws codebuild create-project --region \
--name \
--artifacts type=NO_ARTIFACTS \
--environment "type=LINUX_CONTAINER,
computeType=BUILD_GENERAL1_SMALL,
image=aws/codebuild/amazonlinux-x86_64-standard:5.0" \
--service-role \
--source "type=GITHUB,
location=,
auth={type=SECRETS_MANAGER,resource=}" \
--secondary-sources "type=GITHUB,
location=,
auth={type=SECRETS_MANAGER,resource=},
sourceIdentifier=secondary"
aws codebuild start-build --region --project-name
```
------
### プロジェクトレベルのソース認証情報のフォールバックを設定
プロジェクトレベルのソース認証情報のフォールバックを設定するには、プロジェクトのプライマリソースに `NO_SOURCE` を使用し、トークンを参照します。
```
aws codebuild create-project \
--name \
--service-role \
--artifacts type=NO_ARTIFACTS \
--environment "type=LINUX_CONTAINER,
computeType=BUILD_GENERAL1_SMALL,
image=aws/codebuild/amazonlinux-x86_64-standard:5.0" \
--service-role \
--source "type=NO_SOURCE,
auth={type=SECRETS_MANAGER,resource=},
buildspec="
--secondary-sources "type=GITHUB,
location=,
sourceIdentifier=secondary"
aws codebuild start-build --region --project-name
```
`NO_SOURCE` を使用する場合、通常、buildspec は外部ソースを使用して [buildspec](build-spec-ref.md) を取得するように直接設定されていないため、ソースモデル内で提供されます。通常、`NO_SOURCE` ソースは buildspec 内からすべての関連するリポジトリのクローンを作成します。設定済みの認証情報をこれらのオペレーションで使用できるようにするには、buildspec で `git-credential-helper` オプションを有効にします。
```
env:
git-credential-helper: yes
```
ビルド中、CodeBuild は設定されたトークンから `AuthServer` フィールドを読み取り、その特定のサードパーティソースプロバイダへのすべての git リクエストにトークン認証情報を使用します。
## 追加のセットアップオプション
CloudFormation テンプレートを使用して Secrets Manager のアカウントレベルの認証情報を設定できます。次の CloudFormation テンプレートを使用して、アカウントレベルの認証情報を設定できます。
```
Parameters:
GitHubToken:
Type: String
NoEcho: true
Default: placeholder
Resources:
CodeBuildAuthTokenSecret:
Type: AWS::SecretsManager::Secret
Properties:
Description: CodeBuild auth token
Name: codebuild-auth-token
SecretString:
!Join
- ''
- - '{"ServerType":"GITHUB","AuthType":"PERSONAL_ACCESS_TOKEN","Token":"'
- !Ref GitHubToken
- '"}'
Tags:
- Key: codebuild:source:provider
Value: github
- Key: codebuild:source:type
Value: personal_access_token
CodeBuildSecretsManagerAccountCredential:
Type: AWS::CodeBuild::SourceCredential
Properties:
ServerType: GITHUB
AuthType: SECRETS_MANAGER
Token: !Ref CodeBuildAuthTokenSecret
```
**注記**
同じスタックにプロジェクトを作成する場合は、[DependsOn](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-attribute-dependson.html) CloudFormation 属性を使用して、プロジェクトの前に `AccountCredential` が作成されていることを確認します。
CloudFormation テンプレートを使用して Secrets Manager の複数のソースレベルの認証情報を設定することもできます。次の CloudFormation テンプレートを使用して、複数のトークンを使用して複数のソースをプルできます。
```
Parameters:
GitHubTokenOne:
Type: String
NoEcho: true
Default: placeholder
GitHubTokenTwo:
Type: String
NoEcho: true
Default: placeholder
Resources:
CodeBuildSecretsManagerProject:
Type: AWS::CodeBuild::Project
Properties:
Name: codebuild-multitoken-example
ServiceRole:
Environment:
Type: LINUX_CONTAINER
ComputeType: BUILD_GENERAL1_SMALL
Image: aws/codebuild/amazonlinux-x86_64-standard:5.0
Source:
Type: GITHUB
Location:
Auth:
Type: SECRETS_MANAGER
Resource: !Ref CodeBuildAuthTokenSecretOne
SecondarySources:
- Type: GITHUB
Location:
Auth:
Type: SECRETS_MANAGER
Resource: !Ref CodeBuildAuthTokenSecretTwo
SourceIdentifier: secondary
Artifacts:
Type: NO_ARTIFACTS
LogsConfig:
CloudWatchLogs:
Status: ENABLED
CodeBuildProjectIAMRoleSecretAccess:
Type: AWS::IAM::RolePolicy
Properties:
RoleName:
PolicyName: CodeBuildProjectIAMRoleSecretAccessPolicy
PolicyDocument:
Version: '2012-10-17 '
Statement:
- Effect: Allow
Action:
- secretsmanager:GetSecretValue
Resource:
- !Ref CodeBuildAuthTokenSecretOne
- !Ref CodeBuildAuthTokenSecretTwo
CodeBuildAuthTokenSecretOne:
Type: AWS::SecretsManager::Secret
Properties:
Description: CodeBuild auth token one
Name: codebuild-auth-token-one
SecretString:
!Join
- ''
- - '{"ServerType":"GITHUB","AuthType":"PERSONAL_ACCESS_TOKEN","Token":"'
- !Ref GitHubTokenOne
- '"}'
Tags:
- Key: codebuild:source:provider
Value: github
- Key: codebuild:source:type
Value: personal_access_token
CodeBuildAuthTokenSecretTwo:
Type: AWS::SecretsManager::Secret
Properties:
Description: CodeBuild auth token two
Name: codebuild-auth-token-two
SecretString:
!Join
- ''
- - '{"ServerType":"GITHUB","AuthType":"PERSONAL_ACCESS_TOKEN","Token":"'
- !Ref GitHubTokenTwo
- '"}'
Tags:
- Key: codebuild:source:provider
Value: github
- Key: codebuild:source:type
Value: personal_access_token
```
# AWS CodeBuild でビルドプロジェクトを削除
CodeBuild コンソール、AWS CLI、または AWS SDK を使用して、CodeBuild のビルドプロジェクトを削除できます。プロジェクトを削除しても、そのビルドは削除されません。
**警告**
ビルドとリソースポリシーを持つプロジェクトは削除できません。リソースポリシーとビルドを持つプロジェクトを削除するには、最初にリソースポリシーを削除し、そのビルドを削除する必要があります。
**Topics**
+ [
## ビルドプロジェクトの削除 (コンソール)
](#delete-project-console)
+ [
## ビルドプロジェクトの削除 (AWS CLI)
](#delete-project-cli)
+ [
## ビルドプロジェクトの削除 (AWS SDK)
](#delete-project-sdks)
## ビルドプロジェクトの削除 (コンソール)
1. AWS CodeBuild コンソール ([https://console.aws.amazon.com/codesuite/codebuild/home](https://console.aws.amazon.com/codesuite/codebuild/home)) を開きます。
1. ナビゲーションペインで、[**Build projects**] を選択します。
1. 次のいずれかを行ってください。
+ 削除するビルドプロジェクトの横にあるラジオボタンを選択して、[**削除**] を選択します。
+ 削除するビルドプロジェクトのリンクを選択し、[**Delete**] を選択します。
**注記**
デフォルトでは、最新の 10 個のビルドプロジェクトのみが表示されます。さらに多くのビルドプロジェクトを表示するには、[**Projects per page**] で別の値を選択するか、[Viewing projects] で前後の矢印を選択します。
## ビルドプロジェクトの削除 (AWS CLI)
1. `delete-project` コマンドを実行します。
```
aws codebuild delete-project --name name
```
次のプレースホルダを置き換えます。
+ *name*: 必須の文字列。削除するビルドプロジェクトの名前。使用可能なビルドプロジェクトのリストを取得するには、`list-projects` コマンドを実行します。詳細については、「[ビルドプロジェクト名の一覧表示 (AWS CLI)](view-project-list.md#view-project-list-cli)」を参照してください。
1. 成功した場合、データは出力されず、エラーも出力に表示されません。
AWS CLI を AWS CodeBuild と組み合わせて使用する方法については、「[コマンドラインリファレンス](cmd-ref.md)」を参照してください。
## ビルドプロジェクトの削除 (AWS SDK)
AWS CodeBuild を AWS SDK と組み合わせて使用する方法については、「[AWS SDKsとツールのリファレンス](sdk-ref.md)」を参照してください。
# パブリックビルドプロジェクトの URL を取得
AWS CodeBuild を使うと、ビルドプロジェクトのビルド結果、ログ、アーティファクトを一般ユーザーに公開できます。これにより、ソースリポジトリのコントリビューターは、AWS アカウントへのアクセスを必要とせずに、ビルドの結果を表示したり、アーティファクトをダウンロードしたりできます。
プロジェクトのビルドを一般に公開すると、プロジェクトがプライベートだったときに実行されたビルドも含めて、プロジェクトのビルド結果、ログ、アーティファクトはすべて、一般に公開されます。同様に、パブリックビルドプロジェクトをプライベートにすると、そのプロジェクトのビルド結果は一般に公開されなくなります。
プロジェクトのビルド結果の公開範囲を変更する方法については、「[パブリックビルドアクセスを有効にする](change-project.md#change-project-console.public-builds)」を参照してください。
CodeBuild では、お客様のプロジェクトに固有のパブリックビルド用 URL を提供しています。
ビルドプロジェクトのパブリック URL を取得するには、以下の手順を実行します。
**パブリックビルドプロジェクトの URL を取得するには**
1. AWS CodeBuild コンソール ([https://console.aws.amazon.com/codesuite/codebuild/home](https://console.aws.amazon.com/codesuite/codebuild/home)) を開きます。
1. ナビゲーションペインで、[**Build projects**] を選択します。
1. パブリック URL を取得したいビルドプロジェクトのリンクを選択します。
1. パブリック URL は、[**Configuration**] (構成) セクションの [**Public project URL**] (パブリックプロジェクト URL) フィールドに表示されます。リンクを選択して URL を開くか、コピーボタンを使用して URL をコピーすることができます。
**警告**
プロジェクトのビルド結果を一般に公開する際には、以下に留意してください。
プロジェクトがプライベートだったときに実行されたビルドも含めて、プロジェクトのビルド結果、ログ、アーティファクトはすべて、一般に公開されます。
すべてのビルドログとアーティファクトが一般に公開されます。環境変数、ソースコード、およびその他の機密情報がビルドログとアーティファクトに出力されている可能性があります。ビルドログに出力される情報には注意が必要です。以下にベストプラクティスを示します。
機密値、特に AWS アクセスキー ID やシークレットアクセスキーを格納する場合には、環境変数を使用しないようにします。Amazon EC2 Systems Manager パラメータストアまたは AWS Secrets Manager を使用して機密値を格納することをお勧めします。
[ウェブフック使用のベストプラクティス。](webhooks.md#webhook-best-practices) に従って、ビルドをトリガーできるエンティティを制限し、buildspec をプロジェクト自体に保存しないことで、Webhook を可能な限り安全に保つことができます。
悪意のあるユーザーがパブリックビルドを利用して、悪意のあるアーティファクトを配信する可能性があります。プロジェクト管理者は、すべてのプルリクエストを確認し、プルリクエストが正当な変更であるか検証することをお勧めします。また、チェックサムを使ってすべてのアーティファクトを検証し、正しいアーティファクトがダウンロードされているか確認することを推奨します。
# ビルドプロジェクトを共有
プロジェクト共有を使用すると、プロジェクト所有者は自分の AWS CodeBuild プロジェクトを他の AWS アカウントまたはユーザーと共有できます。このモデルでは、プロジェクトを所有するアカウント (所有者) は、他のアカウント (コンシューマー) とプロジェクトを共有します。コンシューマーは、プロジェクトを編集または実行できません。
**Topics**
+ [
## プロジェクトを共有
](#project-sharing-share)
+ [
## 関連サービス
](#project-sharing-related)
+ [
# 共有されている CodeBuild プロジェクトにアクセス
](project-sharing-access-prereqs.md)
+ [
# 共有プロジェクトを共有解除
](project-sharing-unshare.md)
+ [
# 共有プロジェクトを識別
](project-sharing-identify.md)
+ [
# 共有プロジェクトへのアクセス許可
](project-sharing-perms.md)
## プロジェクトを共有
コンシューマーは、 AWS CLI と AWS CodeBuild コンソールの両方を使用して、共有したプロジェクトとビルドを表示できます。コンシューマーは、プロジェクトを編集または実行できません。
既存のリソース共有にプロジェクトを追加すること、そして、[AWS RAM コンソール](https://console.aws.amazon.com/ram)でプロジェクトを作成することもできます。
**注記**
リソース共有に追加されたビルドを含むプロジェクトは削除できません。
組織単位または組織全体でプロジェクトを共有するには、 AWS Organizationsとの共有を有効にする必要があります。詳細については、*AWS RAM ユーザーガイド*の「[AWS Organizationsで共有を有効化する](https://docs.aws.amazon.com/ram/latest/userguide/getting-started-sharing.html)」を参照してください。
AWS CodeBuild コンソール、 AWS RAM コンソール、または AWS CLI を使用して、所有するプロジェクトを共有できます。
**プロジェクトを共有するための前提条件**
プロジェクトの共有を開始する前に、 AWS アカウントがプロジェクトを所有していることを確認してください。自身が共有を受けているプロジェクトは共有できません。
**所有するプロジェクトを共有するには (CodeBuild コンソール)**
1. [https://console.aws.amazon.com/codesuite/codebuild/home](https://console.aws.amazon.com/codesuite/codebuild/home) で AWS CodeBuild コンソールを開きます。
1. ナビゲーションペインで、[**Build projects**] を選択します。
**注記**
デフォルトでは、最新の 10 個のビルドプロジェクトのみが表示されます。さらに多くのビルドプロジェクトを表示するには、歯車アイコンを選択して [**Projects per page (ページ毎プロジェクト数)**] で別の値を選択するか、前後の矢印を使用します。
1. 共有するプロジェクトを選択し、[**Share (共有)**] を選択します。詳細については、*AWS RAM ユーザーガイド*の「[リソースの共有の作成](https://docs.aws.amazon.com/ram/latest/userguide/getting-started-sharing.html#getting-started-sharing-create)」を参照してください。
**所有しているプロジェクトを共有するには (AWS RAM コンソール)**
「**AWS RAM ユーザーガイド」の「[リソース共有の作成](https://docs.aws.amazon.com/ram/latest/userguide/working-with-sharing.html#working-with-sharing-create)」を参照してください。
**所有しているプロジェクトを共有するには (AWS RAM コマンド)**
[create-resource-share](https://docs.aws.amazon.com/cli/latest/reference/ram/create-resource-share.html) コマンドを使用します。
**所有するプロジェクトを共有するには (CodeBuild コマンド)**
[put-resource-policy](https://docs.aws.amazon.com/cli/latest/reference/codebuild/put-resource-policy.html) コマンドを使用します:
1. `policy.json` という名前のファイルを作成し、その中に次をコピーします。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[{
"Effect":"Allow",
"Action":[
"codebuild:BatchGetProjects",
"codebuild:BatchGetBuilds",
"codebuild:ListBuildsForProject"],
"Resource":"arn:aws:iam::*:role/Service*"
}]
}
```
------
1. 共有するプロジェクト ARN と識別子で `policy.json` を更新します。次の例では、123456789012 で識別される AWS アカウントのルートユーザーに読み取り専用アクセスを許可します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[{
"Effect":"Allow",
"Principal":{
"AWS": [
"123456789012"
]
},
"Action":[
"codebuild:BatchGetProjects",
"codebuild:BatchGetBuilds",
"codebuild:ListBuildsForProject"],
"Resource":"arn:aws:codebuild:us-west-2:123456789012:project/my-project"
}]
}
```
------
1. [put-resource-policy](https://docs.aws.amazon.com/cli/latest/reference/codebuild/put-resource-policy.html) コマンドを使用します。
```
aws codebuild put-resource-policy --resource-arn --policy file://policy.json
```
1. AWS RAM リソース共有 ARN を取得します。
```
aws ram list-resources --resource-owner SELF --resource-arns
```
これにより、次のような応答が得られます。
```
{
"resources": [
{
"arn": "",
"type": "",
"resourceShareArn": "",
"creationTime": "",
"lastUpdatedTime": ""
}
]
}
```
応答から、**値は、次のステップで使用します。
1. AWS RAM [promote-resource-share-created-from-policy](https://docs.aws.amazon.com/cli/latest/reference/ram/promote-resource-share-created-from-policy.html) コマンドを実行します。
```
aws ram promote-resource-share-created-from-policy --resource-share-arn
```
## 関連サービス
プロジェクト共有は AWS Resource Access Manager 、 AWS (AWS RAM) と統合されます。これは、リソースを任意の AWS アカウントまたは を通じて共有できるようにするサービスです AWS Organizations。 AWS RAMでは、リソースを共有するリソースとコンシューマを指定する*リソース共有*を作成して、リソースを共有します。コンシューマーは、個々の AWS アカウント、 の組織単位 AWS Organizations、または の組織全体です AWS Organizations。
詳細については、「*[AWS RAM ユーザーガイド](https://docs.aws.amazon.com/ram/latest/userguide/)*」を参照してください。
# 共有されている CodeBuild プロジェクトにアクセス
共有プロジェクトにアクセスするには、コンシューマーの IAM ロールに `BatchGetProjects` アクセス許可が必要です。次のポリシーを IAM ロールに付けることができます。
```
{
"Effect": "Allow",
"Resource": [
"*"
],
"Action": [
"codebuild:BatchGetProjects"
]
}
```
詳細については、「[でのアイデンティティベースのポリシーの使用 AWS CodeBuild](auth-and-access-control-iam-identity-based-access-control.md)」を参照してください。
# 共有プロジェクトを共有解除
ビルドを含む共有されていないプロジェクトには、その所有者のみがアクセスできます。プロジェクトの共有を解除すると、以前に共有した AWS アカウントまたはユーザーはプロジェクトまたはそのビルドにアクセスできなくなります。
自己所有の共有プロジェクトを共有解除するには、それをリソース共有から削除する必要があります。これ AWS CLI を行うには、 AWS CodeBuild コンソール、 AWS RAM コンソール、または を使用できます。
**所有している共有プロジェクトの共有を解除するには (AWS RAM コンソール)**
*AWS RAM ユーザーガイド* の「[リソース共有の更新](https://docs.aws.amazon.com/ram/latest/userguide/working-with-sharing.html#working-with-sharing-update)」を参照してください。
**所有する共有プロジェクトの共有を解除するには (AWS CLI)**
[disassociate-resource-share](https://docs.aws.amazon.com/cli/latest/reference/ram/disassociate-resource-share.html) コマンドを使用します。
**所有するプロジェクトの共有を解除する (CodeBuild コマンド)**
[delete-resource-policy](https://docs.aws.amazon.com/cli/latest/reference/codebuild/delete-resource-policy.html) コマンドを実行し、共有を解除するプロジェクトの ARN を指定します。
```
aws codebuild delete-resource-policy --resource-arn project-arn
```
# 共有プロジェクトを識別
所有者とコンシューマーは、 AWS CLI を使用して共有プロジェクトを識別できます。
**AWS アカウントまたはユーザーと共有されているプロジェクトを特定するには (AWS CLI)**
[list-shared-projects](https://docs.aws.amazon.com/cli/latest/reference/codebuild/list-shared-projects.html) コマンドを使用して、自分に共有されているプロジェクトを返します。
# 共有プロジェクトへのアクセス許可
## 所有者のアクセス許可
プロジェクトの所有者は、プロジェクトを編集し、それを使用してビルドを実行できます。
## コンシューマーのアクセス許可
プロジェクトコンシューマーは、プロジェクトとそのビルドを表示できますが、プロジェクトを編集したり、プロジェクトを使用してビルドを実行することはできません。
# ビルドプロジェクトをタグ付け
*タグ*は、 AWS リソース AWS に割り当てるカスタム属性ラベルです。各 AWS タグには 2 つの部分があります。
+ タグキー** (`CostCenter`、`Environment`、`Project`、`Secret` など)。タグキーでは、大文字と小文字が区別されます。
+ タグ値**と呼ばれるオプションのフィールド (`111122223333`、`Production`、チーム名など)。タグ値を省略すると、空の文字列を使用した場合と同じになります。タグキーと同様に、タグ値では大文字と小文字が区別されます。
これらは共にキーと値のペアと呼ばれます。プロジェクトに付けることができるタグの最大数、およびタグのキーと値の制限については、「[タグ](limits.md#tag-limits)」を参照してください。
タグは、 AWS リソースの識別と整理に役立ちます。多くの AWS サービスはタグ付けをサポートしているため、異なるサービスのリソースに同じタグを割り当てて、リソースが関連していることを示すことができます。たとえば、S3 バケットに割り当てたものと同じタグを CodeBuild プロジェクトに割り当てることができます。タグの使用の詳細については、「[タグ付けのベストプラクティス](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html)」を参照してください。
CodeBuild では、主なリソースはプロジェクトとレポートグループです。CodeBuild コンソール、 AWS CLI、CodeBuild APIs、または AWS SDKs を使用して、プロジェクトのタグを追加、管理、削除できます。タグを使用して、プロジェクトを識別、整理、追跡するだけでなく、IAM ポリシーでタグを使用して、プロジェクトを表示および操作できるユーザーを管理することもできます。タグベースのアクセスポリシーの例については、「[タグを使用して AWS CodeBuild リソースへのアクセスを制御する](auth-and-access-control-using-tags.md)」を参照してください。
**重要**
リザーブドキャパシティ機能を使用すると、ソースファイル、Docker レイヤー、buildspec で指定されキャッシュされたディレクトリなどを含む、フリートインスタンスにキャッシュされたデータに、同じアカウント内の他のプロジェクトからアクセスできます。これは設計によるもので、同じアカウント内のプロジェクトがフリートインスタンスを共有できるようにしています。
**Topics**
+ [
# プロジェクトにタグを追加する
](how-to-tag-project-add.md)
+ [
# プロジェクトのタグを表示する
](how-to-tag-project-list.md)
+ [
# プロジェクトのタグを編集する
](how-to-tag-project-update.md)
+ [
# プロジェクトからタグを削除する
](how-to-tag-project-delete.md)
# プロジェクトにタグを追加する
プロジェクトにタグを追加すると、 AWS リソースを識別して整理し、リソースへのアクセスを管理するのに役立ちます。まず、プロジェクトに 1 つ以上のタグ (キーと値のペア) を追加します。プロジェクトに付けることができるタグの数には制限があります。キーフィールドおよび値フィールドに使用できる文字には制限があります。詳細については、「[タグ](limits.md#tag-limits)」を参照してください。タグを追加した後、IAM ポリシーを作成して、それらのタグに基づいてプロジェクトへのアクセスを管理できます。CodeBuild コンソールまたは を使用して AWS CLI 、プロジェクトにタグを追加できます。
**重要**
リザーブドキャパシティ機能を使用すると、ソースファイル、Docker レイヤー、buildspec で指定されキャッシュされたディレクトリなどを含む、フリートインスタンスにキャッシュされたデータに、同じアカウント内の他のプロジェクトからアクセスできます。これは設計によるもので、同じアカウント内のプロジェクトがフリートインスタンスを共有できるようにしています。
プロジェクトの作成時にタグを追加する方法の詳細については、「[プロジェクトにタグを追加する (コンソール)](#how-to-tag-project-add-console)」を参照してください。
**重要**
プロジェクトにタグを追加する前に、タグを使用してビルドプロジェクトなどのリソースへのアクセスをコントロールする可能性のある IAM ポリシーを必ず確認してください。タグベースのアクセスポリシーの例については、「[タグを使用して AWS CodeBuild リソースへのアクセスを制御する](auth-and-access-control-using-tags.md)」を参照してください。
**Topics**
+ [
## プロジェクトにタグを追加する (コンソール)
](#how-to-tag-project-add-console)
+ [
## プロジェクトにタグを追加する (AWS CLI)
](#how-to-tag-project-add-cli)
## プロジェクトにタグを追加する (コンソール)
CodeBuild コンソールを使用して、CodeBuild プロジェクトに 1 つ以上のタグを追加できます。
1. CodeBuild コンソール ([https://console.aws.amazon.com/codebuild/](https://console.aws.amazon.com/codebuild/)) を開きます。
1. [**Build projects (ビルドプロジェクト)**] で、タグを追加するプロジェクトの名前を選択します。
1. ナビゲーションペインで **[設定]** を選択します。[**Build project tags (ビルドプロジェクトのタグ)**] を選択します。
1. プロジェクトにいずれのタグも追加されていない場合は、[**Add tag (タグの追加)**] を選択します。それ以外の場合は、[**Edit**]、[**Add tag**] の順に選択します。
1. [**Key**] に、タグの名前を入力します。**[値]** では、任意でタグに値を追加できます。
1. (オプション) 別のタグを追加するには、[**Add tag**] を再度選択します。
1. タグの追加を完了したら、[**Submit**] を選択します。
## プロジェクトにタグを追加する (AWS CLI)
プロジェクトの作成時にタグを追加するには、「[ビルドプロジェクトの作成 (AWS CLI)](create-project.md#create-project-cli)」を参照してください。`create-project.json` で、タグを追加します。
以下のステップでは、 AWS CLI の最新版を既にインストールしているか、最新版に更新しているものと想定します。詳細については、「[AWS Command Line Interfaceのインストール](https://docs.aws.amazon.com/cli/latest/userguide/installing.html)」を参照してください。
成功すると、このコマンドは何も返しません。
# プロジェクトのタグを表示する
タグは、 AWS リソースを識別して整理し、リソースへのアクセスを管理するのに役立ちます。タグの使用の詳細については、「[タグ付けのベストプラクティス](https://d1.awsstatic.com/whitepapers/aws-tagging-best-practices.pdf)」ホワイトペーパーを参照してください。タグベースのアクセスポリシーの例については、「[タグを使用して AWS CodeBuild リソースへのアクセスを制御する](auth-and-access-control-using-tags.md)」を参照してください。
## プロジェクトのタグを表示する (コンソール)
CodeBuild コンソールを使用して、CodeBuild プロジェクトに関連付けられたタグを表示できます。
1. CodeBuild コンソール ([https://console.aws.amazon.com/codebuild/](https://console.aws.amazon.com/codebuild/)) を開きます。
1. [**Build projects (ビルドプロジェクトの)**] で、タグを表示するプロジェクトの名前を選択します。
1. ナビゲーションペインで **[設定]** を選択します。[**Build project tags (ビルドプロジェクトのタグ)**] を選択します。
## プロジェクトのタグを表示する (AWS CLI)
ビルドプロジェクトのタグを表示するには、以下のコマンドを実行します。`--names` パラメータにはプロジェクトの名前を使用します。
```
aws codebuild batch-get-projects --names your-project-name
```
成功すると、このコマンドは、ビルドプロジェクトに関する以下のような JSON 形式の情報を返します。
```
{
"tags": {
"Status": "Secret",
"Team": "JanesProject"
}
}
```
プロジェクトにいずれのタグも追加されていない場合、`tags` セクションは空になります。
```
"tags": []
```
# プロジェクトのタグを編集する
プロジェクトに関連付けられたタグの値を変更できます。キーの名前を変更することもできます。これは、現在のタグを削除して、新しい名前と他のタグと同じ値を持つ、別のタグを追加することになります。キーフィールドと値フィールドに使用できる文字には制限があることにご注意ください。詳細については、「[タグ](limits.md#tag-limits)」を参照してください。
**重要**
プロジェクトのタグを編集すると、そのプロジェクトへのアクセスに影響を与える可能性があります。プロジェクトのタグの名前 (キー) または値を編集する前に、タグのキーや値を使用してビルドプロジェクトなどのリソースへのアクセスをコントロールする可能性のある IAM ポリシーを必ず確認してください。タグベースのアクセスポリシーの例については、「[タグを使用して AWS CodeBuild リソースへのアクセスを制御する](auth-and-access-control-using-tags.md)」を参照してください。
## プロジェクトのタグを編集する (コンソール)
CodeBuild コンソールを使用して、CodeBuild プロジェクトに関連付けられたタグを表示できます。
1. CodeBuild コンソール ([https://console.aws.amazon.com/codebuild/](https://console.aws.amazon.com/codebuild/)) を開きます。
1. [**Build projects (ビルドプロジェクト)**] で、タグを編集するプロジェクトの名前を選択します。
1. ナビゲーションペインで **[設定]** を選択します。[**Build project tags (ビルドプロジェクトのタグ)**] を選択します。
1. **[編集]** を選択します。
1. 次のいずれかを行ってください。
+ タグを変更するには、[**Key**] に新しい名前を入力します。タグの名前を変更することは、タグを削除して、新しいキー名を持つタグを追加することになります。
+ タグの値を変更するには、新しい値を入力します。値を空にする場合は、現在の値を削除してフィールドを空のままにします。
1. タグの編集を完了したら、[**Submit**] を選択します。
## プロジェクトのタグを編集する (AWS CLI)
ビルドプロジェクトのタグを追加、変更、または削除するには、「[ビルドプロジェクトの設定の変更 (AWS CLI)](change-project.md#change-project-cli)」を参照してください。プロジェクトの更新に使用する JSON 形式のデータの `tags` セクションを更新します。
# プロジェクトからタグを削除する
プロジェクトに関連付けられた 1 つ以上のタグを削除できます。タグを削除しても、そのタグに関連付けられている他の AWS リソースからタグは削除されません。
**重要**
プロジェクトからタグを削除すると、そのプロジェクトへのアクセスに影響を与える可能性があります。プロジェクトからタグを削除する前に、タグのキーや値を使用してビルドプロジェクトなどのリソースへのアクセスをコントロールする可能性のある IAM ポリシーを必ず確認してください。タグベースのアクセスポリシーの例については、「[タグを使用して AWS CodeBuild リソースへのアクセスを制御する](auth-and-access-control-using-tags.md)」を参照してください。
## プロジェクトからタグを削除する (コンソール)
CodeBuild コンソールを使用して、タグと CodeBuild プロジェクトとの関連付けを解除できます。
1. CodeBuild コンソール ([https://console.aws.amazon.com/codebuild/](https://console.aws.amazon.com/codebuild/)) を開きます。
1. [**Build projects (ビルドプロジェクト)**] で、タグを削除するプロジェクトの名前を選択します。
1. ナビゲーションペインで **[設定]** を選択します。[**Build project tags (ビルドプロジェクトのタグ)**] を選択します。
1. **[編集]** を選択します。
1. 削除するタグを見つけ、[**Remove tag**] を選択します。
1. タグの削除を完了したら、[**Submit**] を選択します。
## プロジェクトからタグを削除する (AWS CLI)
ビルドプロジェクトから 1 つ以上のタグを削除するには、「[ビルドプロジェクトの設定の変更 (AWS CLI)](change-project.md#change-project-cli)」を参照してください。JSON 形式のデータの `tags` セクションを、削除するタグが含まれていない最新のタグのリストで更新します。すべてのタグを削除する場合は、`tags` セクションを以下のように更新します。
```
"tags: []"
```
**注記**
CodeBuild ビルドプロジェクトを削除すると、削除されたビルドプロジェクトからすべてのタグの関連付けが解除されます。ビルドプロジェクトを削除する前にタグを削除する必要はありません。
# でランナーを使用する AWS CodeBuild
AWS CodeBuild は、GitHub Actions ランナー、セルフマネージド GitLab ランナー、および Buildkite ランナーとの統合をサポートしています。
**Topics**
+ [
# のセルフホスト型 GitHub Actions ランナー AWS CodeBuild
](action-runner-overview.md)
+ [
# のセルフマネージド型 GitLab ランナー AWS CodeBuild
](gitlab-runner.md)
+ [
# のセルフマネージド Buildkite ランナー AWS CodeBuild
](buildkite-runner.md)
# のセルフホスト型 GitHub Actions ランナー AWS CodeBuild
CodeBuild コンテナにセルフホスト型 GitHub Actions ランナーを設定して、GitHub Actions ワークフロージョブを処理するようにプロジェクトを構成できます。これは、CodeBuild プロジェクトを使用してウェブフックを設定し、CodeBuild マシンでホストされているセルフホスト型ランナーを使用するように GitHub Actions ワークフロー YAML を更新することによって実行できます。
GitHub Actions ジョブを実行するように CodeBuild プロジェクトを設定する大まかな手順は次のとおりです。
1. まだ行っていない場合は、個人用アクセストークンを作成するか、OAuth アプリに接続してプロジェクトを GitHub に接続します。
1. CodeBuild コンソールに移動し、ウェブフックを使用して CodeBuild プロジェクトを作成し、ウェブフックフィルタを設定します。
1. GitHub の GitHub Actions ワークフロー YAML を更新して、ビルド環境を設定します。
より詳細な手順については、「[チュートリアル: CodeBuild がホストする GitHub Actions ランナーを設定](action-runner.md)」を参照してください。
この機能を使用すると、GitHub Actions ワークフロージョブを とネイティブに統合できます。これにより AWS、IAM、統合、 AWS Secrets Manager Amazon VPC などの機能を通じてセキュリティ AWS CloudTrailと利便性が提供されます。ARM ベースのインスタンスなど、最新のインスタンスタイプにアクセスできます。
**Topics**
+ [
# CodeBuild がホストする GitHub Actions ランナーについて
](action-runner-questions.md)
+ [
# チュートリアル: CodeBuild がホストする GitHub Actions ランナーを設定
](action-runner.md)
+ [
# ウェブフックのトラブルシューティング
](action-runner-troubleshoot-webhook.md)
+ [
# CodeBuild がホストする GitHub Actions ランナーでサポートされているラベルの上書き
](sample-github-action-runners-update-labels.md)
+ [
# CodeBuild がホストする GitHub Actions ランナーでサポートされているコンピューティングイメージ
](sample-github-action-runners-update-yaml.images.md)
# CodeBuild がホストする GitHub Actions ランナーについて
以下は、CodeBuild がホストする GitHub Actions ランナーに関する、よくある質問です。
## ラベルにイメージとインスタンスの上書きを含める必要があるのはいつですか。
イメージとインスタンスの上書きをラベルに含めることで、GitHub Actions ワークフロージョブごとに異なるビルド環境を指定できます。これは、複数の CodeBuild プロジェクトやウェブフックを作成しなくても実行できます。例えば、[ワークフロージョブにマトリックス](https://docs.github.com/en/actions/using-jobs/using-a-matrix-for-your-jobs)を使用する必要がある場合に便利です。
```
name: Hello World
on: [push]
jobs:
Hello-World-Job:
runs-on:
- codebuild-myProject-${{ github.run_id }}-${{ github.run_attempt }}
image:${{ matrix.os }}
instance-size:${{ matrix.size }}
strategy:
matrix:
include:
- os: arm-3.0
size: small
- os: linux-5.0
size: large
steps:
- run: echo "Hello World!"
```
**注記**
`runs-on` に GitHub Actions コンテキストを含む複数のラベルがある場合、引用符が必要になる場合があります。
## この機能 CloudFormation に を使用できますか?
はい。プロジェクトのウェブフックで GitHub Actions ワークフロージョブイベントフィルターを指定するフィルターグループを CloudFormation テンプレートに含めることができます。
```
Triggers:
Webhook: true
FilterGroups:
- - Type: EVENT
Pattern: WORKFLOW_JOB_QUEUED
```
詳細については、「[GitHub ウェブフックイベントのフィルタリング (CloudFormation)](github-webhook-events-cfn.md)」を参照してください。
CloudFormation テンプレートでプロジェクト認証情報の設定に関するヘルプが必要な場合は、*AWS CloudFormation 「 ユーザーガイド*」の[AWS::CodeBuild::SourceCredential](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-codebuild-sourcecredential.html)」を参照してください。
## この機能を使用する際にシークレットをマスクするにはどうすればよいですか。
デフォルトでは、ログに出力されるシークレットはマスクされません。シークレットをマスクする場合は、次の構文を使用できます。`::add-mask::value`。次に、YAML でこの構文を使用する方法の例を示します。
```
name: Secret Job
on: [push]
jobs:
Secret-Job:
runs-on: codebuild-myProject-${{ github.run_id }}-${{ github.run_attempt }}
env:
SECRET_NAME: "secret-name"
steps:
- run: echo "::add-mask::$SECRET_NAME"
```
詳細については、GitHub の「[Masking a value in a log](https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions#masking-a-value-in-a-log)」を参照してください。
## 単一プロジェクト内の複数のリポジトリから GitHub Actions ウェブフックイベントを受信することはできますか。
CodeBuild は、指定された組織またはエンタープライズからイベントを受信する、組織レベルおよびグローバルレベルのウェブフックをサポートします。詳細については、「[GitHub グローバルおよび組織のウェブフック](github-global-organization-webhook.md)」を参照してください。
## CodeBuild がホストする GitHub Actions ランナーの使用をサポートしているリージョンはどれですか。
CodeBuild がホストする GitHub Actions ランナーは、すべての CodeBuild リージョンでサポートされています。CodeBuild が利用可能な AWS リージョン 場所の詳細については、[AWS 「リージョン別のサービス](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/)」を参照してください。
## CodeBuild がホストする GitHub Actions ランナーの使用をサポートしているプラットフォームはどれですか。
CodeBuild がホストする GitHub Actions ランナーは、Amazon EC2 と [AWS Lambda](lambda.md) コンピューティングの両方でサポートされています。Amazon Linux 2、Amazon Linux 2023、Ubuntu、Windows Server Core 2019 のプラットフォームを使用できます。詳細については、「[EC2 コンピューティングイメージ](ec2-compute-images.md)」および「[Lambda コンピューティングイメージ](lambda-compute-images.md)」を参照してください。
# チュートリアル: CodeBuild がホストする GitHub Actions ランナーを設定
このチュートリアルでは、CodeBuild プロジェクトを設定して GitHub Actions ジョブを実行する方法について説明します。CodeBuild で GitHub Actions を使用する方法の詳細については、「[チュートリアル: CodeBuild がホストする GitHub Actions ランナーを設定](#action-runner)」を参照してください。
このチュートリアルを完了するには、まず以下を行う必要があります。
+ 個人用アクセストークン、Secrets Manager シークレット、OAuth アプリ、または GitHub アプリに接続します。OAuth アプリを使用して接続する場合は、CodeBuild コンソールを使用して接続する必要があります。個人用アクセストークンを作成する場合は、CodeBuild コンソールを使用するか、[ImportSourceCredentials API](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_ImportSourceCredentials.html) を使用できます。詳細な手順については、「[CodeBuild の GitHub および GitHub Enterprise Server アクセス](access-tokens-github-overview.md)」を参照してください。
+ CodeBuild を GitHub アカウントに接続します。これを行うには、次のいずれかで実行できます。
+ コンソールで GitHub をソースプロバイダーとして追加できます。個人用アクセストークン、Secrets Manager シークレット、OAuth アプリ、または GitHub アプリのいずれかを使用して接続できます。手順については、「[CodeBuild の GitHub および GitHub Enterprise Server アクセス](access-tokens-github-overview.md)」を参照してください。
+ GitHub 認証情報は、[ImportSourceCredentials API](https://docs.aws.amazon.com/cli/latest/reference/codebuild/import-source-credentials.html) 経由でインポートできます。これは、個人用アクセストークンでのみ実行できます。OAuth アプリを使用して接続する場合は、代わりにコンソールを使用して接続する必要があります。手順については、「[GitHub をアクセストークンで接続する（CLI）](access-tokens-github.md#access-tokens-github-cli)」を参照してください。
**注記**
これを行う必要があるのは、アカウントで GitHub に接続していない場合のみです。
## ステップ 1: ウェブフックを使用して CodeBuild プロジェクトを作成
このステップでは、ウェブフックを使用して CodeBuild プロジェクトを作成し、GitHub コンソールで確認します。ソースプロバイダとして GitHub Enterprise を選択することもできます。GitHub Enterprise 内でウェブフックを作成する方法の詳細については、「[GitHub 手動ウェブフック](github-manual-webhook.md)」を参照してください。
**ウェブフックを使用して CodeBuild プロジェクトを作成するには**
1. [https://console.aws.amazon.com/codesuite/codebuild/home](https://console.aws.amazon.com/codesuite/codebuild/home) で AWS CodeBuild コンソールを開きます。
1. ビルドプロジェクトを作成します。詳細については、「[ビルドプロジェクトの作成 (コンソール)](create-project.md#create-project-console)」および「[ビルドの実行 (コンソール)](run-build-console.md)」を参照してください。
1. **[プロジェクトタイプ]** で、**[ランナープロジェクト]** を選択します。
**[ランナー]** で、次のようにします。
1. **[ランナープロバイダー]** で **[GitHub]** を選択します。
1. **[ランナーの場所]** で、**[リポジトリ]** を選択します。
1. **[リポジトリ]** の下にあるリポジトリ URL で、**https://github.com/user-name/repository-name** を選択します。
**注記**
デフォルトでは、プロジェクトは単一リポジトリの `WORKFLOW_JOB_QUEUED` イベントのみを受信します。組織またはエンタープライズ内のすべてのリポジトリのイベントを受信する場合は、「[GitHub グローバルおよび組織のウェブフック](github-global-organization-webhook.md)」を参照してください。
1.
+ [**環境**] で以下の操作を行います。
+ サポートされている **[環境イメージ]** と **[コンピューティング]** を選択します。GitHub Actions ワークフロー YAML のラベルを使用して、イメージとインスタンスの設定を上書きするオプションがあることに注意してください。詳細については、[ステップ 2: GitHub Actions ワークフロー YAML を更新](#sample-github-action-runners-update-yaml)を参照してください。
+ [**Buildspec (Buildspec)**] で、次のようにします。
+ `buildspec-override:true` がラベルとして追加されない限り、buildspec は無視されることに注意してください。代わりに、CodeBuild は、セルフホスト型ランナーを設定するコマンドを使用するように上書きします。
1. デフォルト値のまま続行し、**[ビルドプロジェクトを作成する]** を選択します。
1. `https://github.com/user-name/repository-name/settings/hooks` で GitHub コンソールを開き、ウェブフックが作成され、**[ワークフロージョブ]** イベントの配信が有効になっていることを確認します。
## ステップ 2: GitHub Actions ワークフロー YAML を更新
このステップでは、[https://github.com/](https://github.com/) で GitHub Actions ワークフロー YAML ファイルを更新してビルド環境を設定し、CodeBuild で GitHub Actions セルフホスト型ランナーを使用します。詳細については、「[Using labels with self-hosted runners](https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/using-labels-with-self-hosted-runners)」および「[CodeBuild がホストする GitHub Actions ランナーでサポートされているラベルの上書き](sample-github-action-runners-update-labels.md)」を参照してください。
### GitHub Actions ワークフロー YAML を更新
[https://github.com/](https://github.com/) に移動し、GitHub Actions ワークフロー YAML の [https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/using-labels-with-self-hosted-runners](https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/using-labels-with-self-hosted-runners) の設定を更新して、ビルド環境を設定します。これを行うには、次のいずれかで実行できます。
+ プロジェクト名と実行 ID を指定できます。その場合、ビルドはコンピューティング、イメージ、イメージバージョン、インスタンスサイズに既存のプロジェクト設定を使用します。GitHub Actions ジョブの AWS関連の設定を特定の CodeBuild プロジェクトにリンクするには、プロジェクト名が必要です。YAML にプロジェクト名を含めることで、CodeBuild は正しいプロジェクト設定でジョブを呼び出すことができます。実行 ID を指定することで、CodeBuild はビルドを特定のワークフロー実行にマッピングし、ワークフロー実行がキャンセルされたときにビルドを停止します。詳細については、「[`github` context](https://docs.github.com/en/actions/learn-github-actions/contexts#github-context)」を参照してください。
```
runs-on: codebuild--${{ github.run_id }}-${{ github.run_attempt }}
```
**注記**
** が、前のステップで作成したプロジェクトの名前と一致していることを確認してください。一致しない場合、CodeBuild はウェブフックを処理せず、GitHub Actions ワークフローがハングする可能性があります。
次に、GitHub Actions ワークフロー YAML の例を示します。
```
name: Hello World
on: [push]
jobs:
Hello-World-Job:
runs-on:
- codebuild-myProject-${{ github.run_id }}-${{ github.run_attempt }}
steps:
- run: echo "Hello World!"
```
+ ラベル内のイメージとコンピューティングタイプを上書きすることもできます。選別されたイメージのリストについては、「[CodeBuild がホストする GitHub Actions ランナーでサポートされているコンピューティングイメージ](sample-github-action-runners-update-yaml.images.md)」を参照してください。カスタムイメージの使用については、「[CodeBuild がホストする GitHub Actions ランナーでサポートされているラベルの上書き](sample-github-action-runners-update-labels.md)」を参照してください。ラベル内のコンピューティングタイプとイメージは、プロジェクトの環境設定を上書きします。CodeBuild EC2 または Lambda コンピューティングビルドの環境設定を上書きするには、次の構文を使用します。
```
runs-on:
- codebuild--${{ github.run_id }}-${{ github.run_attempt }}
image:-
instance-size:
```
次に、GitHub Actions ワークフロー YAML の例を示します。
```
name: Hello World
on: [push]
jobs:
Hello-World-Job:
runs-on:
- codebuild-myProject-${{ github.run_id }}-${{ github.run_attempt }}
image:arm-3.0
instance-size:small
steps:
- run: echo "Hello World!"
```
+ ラベル内のビルドに使用するフリートを上書きできます。これにより、プロジェクトで設定されたフリート設定が上書きされ、指定されたフリートが使用されます。詳細については、「[リザーブドキャパシティキャパシティフリートでビルドを実行](fleets.md)」を参照してください。Amazon EC2 コンピューティングビルドのフリート設定を上書きするには、次の構文を使用します。
```
runs-on:
- codebuild--${{ github.run_id }}-${{ github.run_attempt }}
fleet:
```
ビルドに使用されるフリートとイメージの両方を上書きするには、次の構文を使用します。
```
runs-on:
- codebuild--${{ github.run_id }}-${{ github.run_attempt }}
fleet:
image:-
```
次に、GitHub Actions ワークフロー YAML の例を示します。
```
name: Hello World
on: [push]
jobs:
Hello-World-Job:
runs-on:
- codebuild-myProject-${{ github.run_id }}-${{ github.run_attempt }}
fleet:myFleet
image:arm-3.0
steps:
- run: echo "Hello World!"
```
+ カスタムイメージで GitHub Actions ジョブを実行するには、CodeBuild プロジェクトでカスタムイメージを設定し、イメージ上書きラベルを指定しないようにします。CodeBuild は、イメージ上書きラベルが指定されていない場合、プロジェクトで設定されたイメージを使用します。
+ 必要に応じて、CodeBuild がサポートするラベル以外のラベルを提供できます。これらのラベルは、ビルドの属性を上書きする目的で無視されますが、ウェブフックリクエストは失敗しません。例えば、`testLabel` をラベルとして追加しても、ビルドの実行は妨げられません。
**注記**
GitHub がホストするランナーが提供する依存関係が CodeBuild 環境で利用できない場合は、ワークフロー実行時に GitHub アクションを使用して依存関係をインストールできます。例えば、[https://github.com/actions/setup-python](https://github.com/actions/setup-python) アクションを使用して、ビルド環境に Python をインストールできます。
### INSTALL、PRE\$1BUILD、POST\$1BUILD フェーズで buildspec コマンドを実行
デフォルトでは、CodeBuild はセルフホスト型 GitHub Actions ビルドを実行するときに buildspec コマンドを無視します。ビルド中に buildspec コマンドを実行するには、ラベルにサフィックスとして `buildspec-override:true` を追加できます。
```
runs-on:
- codebuild--${{ github.run_id }}-${{ github.run_attempt }}
buildspec-override:true
```
このコマンドを使用すると、CodeBuild はコンテナのプライマリソースフォルダに `actions-runner` というフォルダを作成します。GitHub Actions ランナーが `BUILD` フェーズ中に起動すると、ランナーはその `actions-runner` ディレクトリで実行されます。
セルフホスト型 GitHub Actions ビルドで buildspec の上書きを使用する場合、いくつかの制限があります。
+ CodeBuild は、セルフホスト型ランナーが `BUILD` フェーズで実行されるため、`BUILD` フェーズ中は buildspec コマンドを実行しません。
+ CodeBuild は、`DOWNLOAD_SOURCE` フェーズ中はプライマリソースもセカンダリソースもダウンロードしません。buildspec ファイルが設定されている場合、プロジェクトのプライマリソースからそのファイルのみがダウンロードされます。
+ ビルドコマンドが `PRE_BUILD` または `INSTALL` フェーズで失敗した場合、CodeBuild はセルフホスト型ランナーを起動せず、GitHub Actions ワークフロージョブは手動でキャンセルする必要があります。
+ CodeBuild は、`DOWNLOAD_SOURCE` フェーズ中にランナートークンを取得します。有効期限は 1 時間です。`PRE_BUILD` または `INSTALL` フェーズが 1 時間を超えると、GitHub セルフホスト型ランナーが起動する前にランナートークンの有効期限が切れる可能性があります。
## ステップ 3: 結果を確認
GitHub Actions ワークフローが実行されるたびに、CodeBuild はウェブフックを介してワークフロージョブイベントを受信します。ワークフロー内のジョブごとに、CodeBuild はビルドを開始して一時的な GitHub Actions ランナーを実行します。ランナーには、単一のワークフロージョブを実行する役割があります。ジョブが完了すると、ランナーおよび関連付けられたビルドプロセスは即座に終了します。
ワークフロージョブログを表示するには、GitHub のリポジトリに移動し、**[アクション]** を選択して、目的のワークフローを選択し、ログを確認する特定の **[ジョブ]** を選択します。
ジョブが CodeBuild のセルフホスト型ランナーによって取得されるのを待っている間に、リクエストされたラベルをログで確認できます。
![\[ジョブのログの読み込み。\]](http://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/images/hello-world-loading.png)
ジョブが完了すると、ジョブのログを表示できるようになります。
![\[ジョブのログ。\]](http://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/images/hello-world-log.png)
## GitHub Actions ランナー設定オプション
プロジェクト設定で次の環境変数を指定して、セルフホスト型ランナーのセットアップ設定を変更できます。
`CODEBUILD_CONFIG_GITHUB_ACTIONS_ORG_REGISTRATION_NAME`
CodeBuild は、この環境変数の値として指定された組織名にセルフホスト型ランナーを登録します。ランナーを組織レベルで登録する方法と必要なアクセス許可の詳細については、「[組織のジャストインタイムランナーの設定を作成する](https://docs.github.com/en/rest/actions/self-hosted-runners?apiVersion=2022-11-28#create-configuration-for-a-just-in-time-runner-for-an-organization)」を参照してください。
`CODEBUILD_CONFIG_GITHUB_ACTIONS_ENTERPRISE_REGISTRATION_NAME`
CodeBuild は、この環境変数の値として指定されたエンタープライズ名にセルフホスト型ランナーを登録します。ランナーをエンタープライズレベルで登録する方法と必要なアクセス許可の詳細については、「[エンタープライズのジャストインタイムランナーの設定を作成する](https://docs.github.com/en/enterprise-server/rest/actions/self-hosted-runners?apiVersion=2022-11-28#create-configuration-for-a-just-in-time-runner-for-an-enterprise)」を参照してください。
エンタープライズランナーは、デフォルトでは組織リポジトリに使用できません。セルフホスト型ランナーがワークフロージョブを取得するには、場合によってはランナーグループのアクセス設定を構成する必要があります。詳細については、「[エンタープライズランナーをリポジトリで使用可能にする](https://docs.github.com/en/enterprise-server/actions/hosting-your-own-runners/managing-self-hosted-runners/adding-self-hosted-runners#making-enterprise-runners-available-to-repositories)」を参照してください。
`CODEBUILD_CONFIG_GITHUB_ACTIONS_RUNNER_GROUP_ID`
CodeBuild は、この環境変数の値として保存されている整数ランナーグループ ID にセルフホスト型ランナーを登録します。デフォルトでは、この値は 1 です。セルフホスト型ランナーグループの詳細については、「[グループを使用したセルフホスト型ランナーへのアクセスの管理](https://docs.github.com/en/rest/actions/self-hosted-runners?apiVersion=2022-11-28#create-configuration-for-a-just-in-time-runner-for-an-organization)」を参照してください。
`CODEBUILD_CONFIG_GITHUB_ACTIONS_ORG_REGISTRATION_NAME`
GitHub Actions ワークフロー YAML ファイルを使用して組織レベルのランナー登録を設定するには、次の構文を使用できます。
```
name: Hello World
on: [push]
jobs:
Hello-World-Job:
runs-on:
- codebuild-myProject-${{ github.run_id }}-${{ github.run_attempt }}
organization-registration-name:myOrganization
steps:
- run: echo "Hello World!"
```
`CODEBUILD_CONFIG_GITHUB_ACTIONS_ENTERPRISE_REGISTRATION_NAME`
GitHub Actions ワークフロー YAML ファイルを使用してエンタープライズレベルのランナー登録を設定するには、次の構文を使用できます。
```
name: Hello World
on: [push]
jobs:
Hello-World-Job:
runs-on:
- codebuild-myProject-${{ github.run_id }}-${{ github.run_attempt }}
enterprise-registration-name:myEnterprise
steps:
- run: echo "Hello World!"
```
`CODEBUILD_CONFIG_GITHUB_ACTIONS_RUNNER_GROUP_ID`
GitHub Actions ワークフロー YAML ファイルを使用して特定のランナーグループ ID へのランナーの登録を設定するには、次の構文を使用できます。
```
name: Hello World
on: [push]
jobs:
Hello-World-Job:
runs-on:
- codebuild-myProject-${{ github.run_id }}-${{ github.run_attempt }}
registration-group-id:3
steps:
- run: echo "Hello World!"
```
## GitHub Actions ウェブフックイベントをフィルタリング (CloudFormation)
CloudFormation テンプレートの次の YAML 形式の部分は、true と評価されたときにビルドをトリガーするフィルタグループを作成します。次のフィルタグループは、正規表現 `\[CI-CodeBuild\]` に一致するワークフロー名を持つ GitHub Actions ワークフロージョブリクエストを指定します。
```
CodeBuildProject:
Type: AWS::CodeBuild::Project
Properties:
Name: MyProject
ServiceRole: service-role
Artifacts:
Type: NO_ARTIFACTS
Environment:
Type: LINUX_CONTAINER
ComputeType: BUILD_GENERAL1_SMALL
Image: aws/codebuild/standard:5.0
Source:
Type: GITHUB
Location: CODEBUILD_DEFAULT_WEBHOOK_SOURCE_LOCATION
Triggers:
Webhook: true
ScopeConfiguration:
Name: organization-name
Scope: GITHUB_ORGANIZATION
FilterGroups:
- - Type: EVENT
Pattern: WORKFLOW_JOB_QUEUED
- Type: WORKFLOW_NAME
Pattern: \[CI-CodeBuild\]
```
## GitHub Actions ウェブフックイベントをフィルタリング (AWS CDK)
次の AWS CDK テンプレートは、ビルドが true と評価されたときにビルドをトリガーするフィルターグループを作成します。次のフィルタグループは、GitHub Actions ワークフロージョブリクエストを指定します。
```
import { aws_codebuild as codebuild } from 'aws-cdk-lib';
import {EventAction, FilterGroup} from "aws-cdk-lib/aws-codebuild";
const source = codebuild.Source.gitHub({
owner: 'owner',
repo: 'repo',
webhook: true,
webhookFilters: [FilterGroup.inEventOf(EventAction.WORKFLOW_JOB_QUEUED)],
})
```
## GitHub Actions ウェブフックイベントをフィルタリング (Terraform)
次の Terraform テンプレートは、true と評価されたときにビルドをトリガーするフィルタグループを作成します。次のフィルタグループは、GitHub Actions ワークフロージョブリクエストを指定します。
```
resource "aws_codebuild_webhook" "example" {
project_name = aws_codebuild_project.example.name
build_type = "BUILD"
filter_group {
filter {
type = "EVENT"
pattern = "WORKFLOW_JOB_QUEUED"
}
}
}
```
## GitHub Actions ウェブフックイベントをフィルタリング (AWS CLI)
次の AWS CLI コマンドは、ビルドが true と評価されたときにビルドをトリガーする GitHub Actions ワークフロージョブリクエストフィルターグループを使用して、セルフホスト型の GitHub Actions ランナープロジェクトを作成します。
```
aws codebuild create-project \
--name \
--source "{\"type\":\"GITHUB\",\"location\":\"\",\"buildspec\":\"\"}" \
--artifacts {"\"type\":\"NO_ARTIFACTS\""} \
--environment "{\"type\": \"LINUX_CONTAINER\",\"image\": \"aws/codebuild/amazonlinux-x86_64-standard:5.0\",\"computeType\": \"BUILD_GENERAL1_MEDIUM\"}" \
--service-role ""
```
```
aws codebuild create-webhook \
--project-name \
--filter-groups "[[{\"type\":\"EVENT\",\"pattern\":\"WORKFLOW_JOB_QUEUED\"}]]"
```
# ウェブフックのトラブルシューティング
**問題:** [チュートリアル: CodeBuild がホストする GitHub Actions ランナーを設定](action-runner.md) で設定したウェブフックが機能していないか、ワークフロージョブが GitHub でハングしています。
**考えられる原因: **
+ ウェブフックの **[ワークフロージョブ]** イベントがビルドのトリガーに失敗している可能性があります。**[レスポンス]** ログを確認して、レスポンスまたはエラーメッセージを表示します。
+ ラベル設定のため、ジョブが誤ったランナーエージェントに割り当てられています。この問題は、1 つのワークフロー実行内のいずれかのジョブのラベルが別のジョブよりも少ない場合に発生する可能性があります。たとえば、同じワークフロー実行に次のラベルを持つ 2 つのジョブがある場合です。
+ **ジョブ 1**: `codebuild-myProject-${{ github.run_id }}-${{ github.run_attempt }}`
+ **ジョブ 2**: `codebuild-myProject-${{ github.run_id }}-${{ github.run_attempt }}`、`instance-size:medium`
セルフホスト型 GitHub Actions ジョブをルーティングする場合、GitHub はジョブのすべての指定されたラベルを持つ任意のランナーにジョブをルーティングします。つまり、**ジョブ 1** は**ジョブ 1** または**ジョブ 2** 用に作成されたランナーによって取得できますが、**ジョブ 2** は、追加のラベルがあるため、**ジョブ 2** 用に作成されたランナーによってのみ取得できます。**ジョブ 1** が**ジョブ 2** 用に作成されたランナーによって取得された場合、**ジョブ 1** ランナーには `instance-size:medium` ラベルがないため、**ジョブ 2** はスタックします。
**推奨される解決策: **
同じワークフロー実行内で複数のジョブを作成する場合は、各ジョブに同じ数のラベル上書きを使用するか、`job1` や `job2` などのカスタムラベルを各ジョブに割り当てます。
エラーが解決されない場合は、次の手順を使用して問題をデバッグします。
1. `https://github.com/user-name/repository-name/settings/hooks` で GitHub コンソールを開き、リポジトリのウェブフック設定を表示します。このページには、リポジトリ用に作成されたウェブフックが表示されます。
1. **[編集]** を選択し、ウェブフックの **[ワークフロージョブ]** イベントの配信が有効になっていることを確認します。
![\[ワークフロージョブイベントは、ウェブフックで有効になっています。\]](http://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/images/github-actions-workflow-jobs.png)
1. **[最近の配信]** タブに移動し、対応する `workflow_job.queued` イベントを見つけて、イベントを展開します。
1. **[ペイロード]** の **[ラベル]** フィールドを確認し、期待どおりに動作していることを確認します。
1. 最後に、**[レスポンス]** タブを確認します。このタブには、CodeBuild から返されたレスポンスまたはエラーメッセージが含まれています。
![\[CodeBuild から返されたレスポンスまたはエラーメッセージ。\]](http://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/images/github-actions-workflow-jobs-response.png)
1. または、GitHub の API を使用してウェブフックの障害をデバッグすることもできます。「[List deliveries for a repository webhook](https://docs.github.com/en/rest/repos/webhooks?apiVersion=2022-11-28#list-deliveries-for-a-repository-webhook)」API を使用して、ウェブフックの最近の配信を表示できます。
```
gh api \
-H "Accept: application/vnd.github+json" \
-H "X-GitHub-Api-Version: 2022-11-28" \
/repos/owner/repo/hooks/hook-id/deliveries
```
デバッグするウェブフック配信を見つけて配信 ID をメモしたら、[Get a delivery for a repository webhook](https://docs.github.com/en/rest/repos/webhooks?apiVersion=2022-11-28#get-a-delivery-for-a-repository-webhook) API を使用できます。ウェブフックの配信ペイロードに対する CodeBuild のレスポンスは、`response` セクションにあります。
```
gh api \
-H "Accept: application/vnd.github+json" \
-H "X-GitHub-Api-Version: 2022-11-28" \
/repos/owner/repo/hooks/hook-id/deliveries/delivery-id
```
**問題:** [デプロイ保護](https://docs.github.com/en/actions/managing-workflow-runs-and-deployments/managing-deployments/reviewing-deployments)ルールが有効になっている GitHub Actions は、デプロイが承認される前に CodeBuild 内でビルドをトリガーします。
**考えられる原因:** CodeBuild は、承認されているかどうかを確認するため、GitHub Actions ジョブに関連付けられているデプロイと環境を取得します (存在する場合)。CodeBuild がデプロイまたは環境の取得に失敗すると、CodeBuild ビルドが早期にトリガーされる可能性があります。
**推奨される解決策:** CodeBuild プロジェクトに関連付けられた認証情報に、GitHub 内のデプロイとアクションに対する読み取りアクセス許可があることを確認します。
# CodeBuild がホストする GitHub Actions ランナーでサポートされているラベルの上書き
GitHub Actions ワークフロー YAML では、セルフホスト型ランナーのビルドを変更するさまざまなラベルの上書きを指定できます。CodeBuild で認識されないビルドは無視されますが、ウェブフックリクエストは失敗しません。例えば、次のワークフロー YAML には、イメージ、インスタンスサイズ、フリート、および buildspec の上書きが含まれます。
```
name: Hello World
on: [push]
jobs:
Hello-World-Job:
runs-on:
- codebuild-myProject-${{ github.run_id }}-${{ github.run_attempt }}
image:${{ matrix.os }}
instance-size:${{ matrix.size }}
fleet:myFleet
buildspec-override:true
strategy:
matrix:
include:
- os: arm-3.0
size: small
- os: linux-5.0
size: large
steps:
- run: echo "Hello World!"
```
**注記**
ワークフロージョブが GitHub でハングアップしている場合は、「[ウェブフックのトラブルシューティング](action-runner-troubleshoot-webhook.md)」および「[カスタムラベルを使用してジョブをルーティングする](https://docs.github.com/en/enterprise-server@3.12/actions/hosting-your-own-runners/managing-self-hosted-runners/using-self-hosted-runners-in-a-workflow?learn=hosting_your_own_runners&learnProduct=actions#using-custom-labels-to-route-jobs)」を参照してください。
`codebuild--${{github.run_id}}-${{github.run_attempt}}` (必須)
+ 例: `codebuild-fake-project-${{ github.run_id }}-${{ github.run_attempt }}`
+ すべての GitHub Actions ワークフロー YAML に必須です。** は、セルフホスト型ランナーウェブフックが設定されているプロジェクトの名前と同じである必要があります。
`image:-`
+ 例: `image:arm-3.0`
+ 選別されたイメージを使用したセルフホスト型ランナーのビルドの開始時に使用するイメージと環境タイプを上書きします。サポートされている値については、「[CodeBuild がホストする GitHub Actions ランナーでサポートされているコンピューティングイメージ](sample-github-action-runners-update-yaml.images.md)」を参照してください。
+ カスタムイメージで使用されるイメージと環境タイプを上書きするには、「`image:custom--`」を使用します。
+ 例: `image:custom-arm-public.ecr.aws/codebuild/amazonlinux-aarch64-standard:3.0`
**注記**
カスタムイメージがプライベートレジストリにある場合は、「[セルフホスト型ランナーのプライベートレジストリ認証情報を設定する](private-registry-sample-configure-runners.md)」を参照してください。
`instance-size:`
+ 例: `instance-size:medium`
+ セルフホスト型ランナーのビルドの開始時に使用するインスタンスタイプを上書きします。サポートされている値については、「[CodeBuild がホストする GitHub Actions ランナーでサポートされているコンピューティングイメージ](sample-github-action-runners-update-yaml.images.md)」を参照してください。
`fleet:`
+ 例: `fleet:myFleet`
+ 指定されたフリートを使用するために、プロジェクトに設定されたフリート設定を上書きします。詳細については、「[リザーブドキャパシティキャパシティフリートでビルドを実行](fleets.md)」を参照してください。
`buildspec-override:`
+ 例: `buildspec-override:true`
+ `true` に設定されている場合、ビルドが `INSTALL`、`PRE_BUILD`、および `POST_BUILD` フェーズで buildspec コマンドを実行できるようにします。
## 単一ラベルの上書き (レガシー)
CodeBuild では、以下を使用して、単一のラベルに複数の上書きを指定できます。
+ Amazon EC2/Lambda コンピューティングビルドの環境設定を上書きするには、次の構文を使用します。
```
runs-on: codebuild--${{ github.run_id }}-${{ github.run_attempt }}---
```
+ Amazon EC2 コンピューティングビルドのフリート設定を上書きするには、次の構文を使用します。
```
runs-on: codebuild--${{ github.run_id }}-${{ github.run_attempt }}-fleet-
```
+ ビルドに使用されるフリートとイメージの両方を上書きするには、次の構文を使用します。
```
runs-on: codebuild--${{ github.run_id }}-${{ github.run_attempt }}-image--fleet-
```
+ ビルド中に buildspec コマンドを実行するには、ラベルにサフィックスとして `-with-buildspec` を追加できます。
```
runs-on: codebuild--${{ github.run_id }}-${{ github.run_attempt }}----with-buildspec
```
+ オプションで、イメージを上書きせずにインスタンスサイズの上書きを指定できます。Amazon EC2 ビルドでは、環境タイプとイメージ識別子の両方を除外できます。Lambda ビルドでは、イメージ識別子を除外できます。
# CodeBuild がホストする GitHub Actions ランナーでサポートされているコンピューティングイメージ
「[チュートリアル: CodeBuild がホストする GitHub Actions ランナーを設定](action-runner.md)」で設定したラベルでは、最初の 3 つの列の値を使用して Amazon EC2 環境設定を上書きできます。CodeBuild では、次の Amazon EC2 コンピューティングイメージが用意されています。詳細については、以下を参照してください。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/sample-github-action-runners-update-yaml.images.html)
さらに、次の値を使用して Lambda 環境設定を上書きできます。CodeBuild Lambda コンピューティングの詳細については、「[AWS Lambda コンピューティングでビルドを実行する](lambda.md)」を参照してください。CodeBuild は、次の Lambda コンピューティングイメージをサポートしています。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/sample-github-action-runners-update-yaml.images.html)
詳細については、「[ビルド環境のコンピューティングモードおよびタイプ](build-env-ref-compute-types.md)」および「[CodeBuild に用意されている Docker イメージ](build-env-ref-available.md)」を参照してください。
# のセルフマネージド型 GitLab ランナー AWS CodeBuild
GitLab には、CI/CD パイプラインで GitLab ジョブを実行するための 2 つの実行モードがあります。1 つのモードは GitLab ホストランナーで、GitLab によって管理され、GitLab と完全に統合されています。もう 1 つのモードはセルフマネージド型ランナーです。これにより、独自のカスタマイズされた環境を導入して、GitLab CI/CD パイプラインでジョブを実行できます。
GitLab CI/CD パイプラインジョブを実行するように CodeBuild プロジェクトを設定する大まかな手順は次のとおりです。
1. まだ行っていない場合は、OAuth アプリを使用してプロジェクトを GitLab に接続します。
1. CodeBuild コンソールに移動し、ウェブフックを使用して CodeBuild プロジェクトを作成し、ウェブフックフィルタを設定します。
1. GitLab で GitLab CI/CD パイプライン YAML を更新して、ビルド環境を設定します。
より詳細な手順については、「[チュートリアル: CodeBuild がホストする GitLab ランナーを設定](sample-gitlab-runners.md)」を参照してください。
この機能を使用すると、GitLab CI/CD パイプラインジョブを AWSとネイティブ統合できます。これにより、IAM、 AWS CloudTrail、Amazon VPC などの機能を通じてセキュリティと利便性が提供されます。ARM ベースのインスタンスなど、最新のインスタンスタイプにアクセスできます。
**Topics**
+ [
# CodeBuild がホストする GitLab ランナーについて
](gitlab-runner-questions.md)
+ [
# チュートリアル: CodeBuild がホストする GitLab ランナーを設定
](sample-gitlab-runners.md)
+ [
# CodeBuild がホストする GitLab ランナーでサポートされているラベルの上書き
](gitlab-runners-update-labels.md)
+ [
# CodeBuild がホストする GitLab ランナーでサポートされているコンピューティングイメージ
](sample-gitlab-runners-gitlab-ci.images.md)
# CodeBuild がホストする GitLab ランナーについて
以下は、CodeBuild がホストする GitLab ランナーに関する、よくある質問です。
## CodeBuild がホストする GitLab ランナーでは、どのようなソースタイプがサポートされていますか?
CodeBuild がホストする GitLab ランナーは、`GITLAB` および `GITLAB_SELF_MANAGED` ソースタイプでサポートされます。
## ラベルにイメージとインスタンスの上書きを含める必要があるのはいつですか。
イメージとインスタンスの上書きをラベルに含めることで、GitLab CI/CD パイプラインジョブごとに異なるビルド環境を指定できます。これは、複数の CodeBuild プロジェクトやウェブフックを作成しなくても実行できます。
## この機能 CloudFormation に を使用できますか?
はい。プロジェクトウェブフックで GitLab ワークフロージョブイベントフィルターを指定するフィルターグループを CloudFormation テンプレートに含めることができます。
```
Triggers:
Webhook: true
FilterGroups:
- - Type: EVENT
Pattern: WORKFLOW_JOB_QUEUED
```
詳細については、「[GitLab ウェブフックイベントのフィルタリング (CloudFormation)](gitlab-webhook-events-cfn.md)」を参照してください。
CloudFormation テンプレートでプロジェクト認証情報の設定に関するヘルプが必要な場合は、「 *AWS CloudFormation ユーザーガイド*」の[AWS::CodeBuild::SourceCredential](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-codebuild-sourcecredential.html)」を参照してください。
## この機能を使用する際にシークレットをマスクするにはどうすればよいですか。
デフォルトでは、ログに出力されるシークレットはマスクされません。シークレットをマスクする場合は、CI/CD 環境変数設定を更新してマスクできます。
**GitLab でシークレットをマスクするには**
1. **[GitLab 設定]** で **[CI/CD]** を選択します。
1. **[変数]** で、マスクするシークレットの **[編集]** を選択します。
1. **[可視性]** で、**[マスク変数]** を選択し、**[変数を更新]** を選択して変更を保存します。
## 単一グループ内の複数のプロジェクトから GitLab ウェブフックイベントを受信することはできますか。
CodeBuild は、指定された GitLab グループからイベントを受信するグループウェブフックをサポートしています。詳細については、「[GitLab グループウェブフック](gitlab-group-webhook.md)」を参照してください。
## セルフマネージド型ランナーの Docker Executor でジョブを実行することはできますか。例えば、特定のイメージでパイプラインジョブを実行して、分離された別のコンテナに同じビルド環境を維持します。
CodeBuild で GitLab セルフマネージド型ランナーを特定のイメージで実行するには、[カスタムイメージを使用してプロジェクトを作成する](create-project.md#environment-image.console)か、`.gitlab-ci.yml` ファイル内の[イメージを上書き](sample-gitlab-runners.md#sample-gitlab-runners-gitlab-ci)します。
## CodeBuild のセルフマネージド型ランナーはどのエグゼキュターで実行されますか。
CodeBuild のセルフマネージド型ランナーはシェルエグゼキュターで実行され、ビルドは Docker コンテナ内で実行されている GitLab ランナーとともにローカルで実行されます。
## セルフマネージド型ランナーと一緒に buildspec コマンドを提供できますか。
はい。セルフマネージド型ランナーと一緒に buildspec コマンドを追加できます。GitLab リポジトリに buildspec.yml ファイルを指定し、ジョブの `buildspec-override:true` タグセクションで **[タグ]** を使用できます。詳細については、「[buildspec ファイル名とストレージの場所](build-spec-ref.md#build-spec-ref-name-storage)」を参照してください。
## CodeBuild がホストする GitLab ランナーの使用をサポートしているリージョンはどれですか。
CodeBuild がホストする GitLab ランナーは、すべての CodeBuild リージョンでサポートされています。CodeBuild が利用可能な AWS リージョン 場所の詳細については、[AWS 「リージョン別のサービス](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/)」を参照してください。
## CodeBuild がホストする GitLab ランナーの使用をサポートしているプラットフォームはどれですか。
CodeBuild がホストする GitLab ランナーは、Amazon EC2 と [AWS Lambda](lambda.md) コンピューティングの両方でサポートされています。Amazon Linux 2、Amazon Linux 2023、Ubuntu、Windows Server Core 2019 のプラットフォームを使用できます。詳細については、「[EC2 コンピューティングイメージ](ec2-compute-images.md)」および「[Lambda コンピューティングイメージ](lambda-compute-images.md)」を参照してください。
# チュートリアル: CodeBuild がホストする GitLab ランナーを設定
このチュートリアルでは、GitLab CI/CD パイプラインジョブを実行するように CodeBuild プロジェクトを設定する方法について説明します。CodeBuild で GitLab または GitLab セルフマネージドを使用する方法の詳細については、「[のセルフマネージド型 GitLab ランナー AWS CodeBuild](gitlab-runner.md)」を参照してください。
このチュートリアルを完了するには、まず以下を行う必要があります。
+ CodeConnections を使用して OAuth アプリに接続します。OAuth アプリに接続する場合は、CodeBuild コンソールを使用して接続する必要があることに注意してください。詳細な手順については、「[CodeBuild での GitLab アクセス](access-tokens-gitlab-overview.md)」を参照してください。
+ CodeBuild を GitLab アカウントに接続します。これを行うには、コンソールで GitLab をソースプロバイダとして追加できます。手順については、「[CodeBuild での GitLab アクセス](access-tokens-gitlab-overview.md)」を参照してください。
**注記**
これを行う必要があるのは、アカウントで GitLab に接続していない場合のみです。
この機能では、CodeBuild に GitLab OAuth アプリからの `create_runner` や `manage_runner` などの追加のアクセス許可が必要です。特定の GitLab アカウントに既存の CodeConnections がある場合、アクセス許可の更新は自動的にリクエストされません。これを行うには、CodeConnections コンソールに移動し、同じ GitLab アカウントへのダミー接続を作成して、追加のアクセス許可を取得するための再認証をトリガーします。これにより、すべての既存の接続でランナー機能を使用できます。完了したら、ダミー接続を削除できます。
## ステップ 1: ウェブフックを使用して CodeBuild プロジェクトを作成
このステップでは、ウェブフックを使用して CodeBuild プロジェクトを作成し、GitLab コンソールで確認します。
**ウェブフックを使用して CodeBuild プロジェクトを作成するには**
1. [https://console.aws.amazon.com/codesuite/codebuild/home](https://console.aws.amazon.com/codesuite/codebuild/home) で AWS CodeBuild コンソールを開きます。
1. ビルドプロジェクトを作成します。詳細については、「[ビルドプロジェクトの作成 (コンソール)](create-project.md#create-project-console)」および「[ビルドの実行 (コンソール)](run-build-console.md)」を参照してください。
**[プロジェクトタイプ]** で、**[ランナープロジェクト]** を選択します。
+ **[ランナー]** で、次のようにします。
+ **[ランナープロバイダ]** で **[GitLab]** を選択します。
+ **[認証情報]** で、次のいずれかを選択します。
+ **[デフォルトソース認証情報]** を選択します。デフォルト接続は、すべてのプロジェクトにデフォルトの GitLab 接続を適用します。
+ **[カスタムソース認証情報]** を選択します。カスタム接続は、アカウントのデフォルト設定を上書きするカスタム GitLab 接続を適用します。
**注記**
プロバイダへの接続をまだ作成していない場合は、新しい GitLab 接続を作成する必要があります。手順については、「[CodeBuild を GitLab に接続](access-tokens-gitlab-overview.md#connections-gitlab)」を参照してください。
+ **[ランナーの場所]** で、**[リポジトリ]** を選択します。
+ **[リポジトリ]** で、プロジェクトのパスと名前空間を指定して、GitLab 内のプロジェクトの名前を選択します。
+ [**環境**] で以下の操作を行います。
+ サポートされている **[環境イメージ]** と **[コンピューティング]** を選択します。GitLab CI/CD パイプライン YAML のラベルを使用して、イメージとインスタンスの設定を上書きするオプションがあることに注意してください。詳細については、「[ステップ 2: リポジトリに .gitlab-ci.yml ファイルを作成](#sample-gitlab-runners-gitlab-ci)」を参照してください。
+ [**Buildspec (Buildspec)**] で、次のようにします。
+ `buildspec-override:true` がラベルとして追加されない限り、buildspec は無視されることに注意してください。代わりに、CodeBuild は、セルフマネージド型ランナーを設定するコマンドを使用するように上書きします。
1. デフォルト値のまま続行し、**[ビルドプロジェクトを作成する]** を選択します。
1. `https://gitlab.com/user-name/repository-name/-/hooks` で GitLab コンソールを開き、ウェブフックが作成され、**[ワークフロージョブ]** イベントの配信が有効になっていることを確認します。
## ステップ 2: リポジトリに .gitlab-ci.yml ファイルを作成
このステップでは、[https://gitlab.com/](https://gitlab.com/) で `.gitlab-ci.yml` ファイルを作成してビルド環境を設定し、CodeBuild で GitLab セルフマネージド型ランナーを使用します。詳細については、「[Use self-managed runners](https://docs.gitlab.com/runner/#use-self-managed-runners)」を参照してください。
### GitLab CI/CD パイプライン YAML を更新
「`https://gitlab.com/user-name/project-name/-/tree/branch-name`」に移動して、リポジトリで `.gitlab-ci.yml` ファイルを作成します。ビルド環境を設定するには、次のいずれかを実行します。
+ CodeBuild プロジェクト名を指定できます。その場合、ビルドはコンピューティング、イメージ、イメージバージョン、インスタンスサイズに既存のプロジェクト設定を使用します。GitLab ジョブの AWS関連の設定を特定の CodeBuild プロジェクトにリンクするには、プロジェクト名が必要です。YAML にプロジェクト名を含めることで、CodeBuild は正しいプロジェクト設定でジョブを呼び出すことができます。
```
tags:
- codebuild--$CI_PROJECT_ID-$CI_PIPELINE_IID-$CI_JOB_NAME
```
`$CI_PROJECT_ID-$CI_PIPELINE_IID-$CI_JOB_NAME` は、ビルドを特定のパイプラインジョブの実行にマッピングし、パイプラインの実行がキャンセルされたときにビルドを停止するために必要です。
**注記**
** が、CodeBuild で作成したプロジェクトの名前と一致していることを確認してください。一致しない場合、CodeBuild はウェブフックを処理せず、GitLab CI/CD パイプラインがハングする可能性があります。
GitLab CI/CD パイプライン YAML の例を次に示します。
```
workflow:
name: HelloWorld
stages: # List of stages for jobs, and their order of execution
- build
build-job: # This job runs in the build stage, which runs first.
stage: build
script:
- echo "Hello World!"
tags:
- codebuild-myProject-$CI_PROJECT_ID-$CI_PIPELINE_IID-$CI_JOB_NAME
```
+ タグ内のイメージとコンピューティングタイプを上書きすることもできます。選別されたイメージのリストについては、「[CodeBuild がホストする GitLab ランナーでサポートされているコンピューティングイメージ](sample-gitlab-runners-gitlab-ci.images.md)」を参照してください。カスタムイメージの使用については、「[CodeBuild がホストする GitLab ランナーでサポートされているラベルの上書き](gitlab-runners-update-labels.md)」を参照してください。タグ内のコンピューティングタイプとイメージは、プロジェクトの環境設定を上書きします。Amazon EC2 コンピューティングビルドの環境設定を上書きするには、次の構文を使用します。
```
tags:
- codebuild--$CI_PROJECT_ID-$CI_PIPELINE_IID-$CI_JOB_NAME
- image:-
- instance-size:
```
GitLab CI/CD パイプライン YAML の例を次に示します。
```
stages:
- build
build-job:
stage: build
script:
- echo "Hello World!"
tags:
- codebuild-myProject-$CI_PROJECT_ID-$CI_PIPELINE_IID-$CI_JOB_NAME
- image:arm-3.0
- instance-size:small
```
+ タグ内のビルドに使用するフリートを上書きできます。これにより、プロジェクトで設定されたフリート設定が上書きされ、指定されたフリートが使用されます。詳細については、「[リザーブドキャパシティキャパシティフリートでビルドを実行](fleets.md)」を参照してください。Amazon EC2 コンピューティングビルドのフリート設定を上書きするには、次の構文を使用します。
```
tags:
- codebuild--$CI_PROJECT_ID-$CI_PIPELINE_IID-$CI_JOB_NAME
- fleet:
```
ビルドに使用されるフリートとイメージの両方を上書きするには、次の構文を使用します。
```
tags:
- codebuild--$CI_PROJECT_ID-$CI_PIPELINE_IID-$CI_JOB_NAME
- fleet:
- image:-
```
GitLab CI/CD パイプライン YAML の例を次に示します。
```
stages:
- build
build-job:
stage: build
script:
- echo "Hello World!"
tags:
- codebuild-myProject-$CI_PROJECT_ID-$CI_PIPELINE_IID-$CI_JOB_NAME
- fleet:myFleet
- image:arm-3.0
```
+ カスタムイメージで GitLab CI/CD パイプラインジョブを実行するには、CodeBuild プロジェクトでカスタムイメージを設定し、イメージ上書きラベルを指定しないようにします。CodeBuild は、イメージ上書きラベルが指定されていない場合、プロジェクトで設定されたイメージを使用します。
`.gitlab-ci.yml` に変更をコミットすると、GitLab パイプラインがトリガーされ、`build-job` からウェブフック通知が送信され、CodeBuild でのビルドが開始されます。
### INSTALL、PRE\$1BUILD、POST\$1BUILD フェーズで buildspec コマンドを実行
デフォルトでは、CodeBuild はセルフマネージド型 GitLab ビルドを実行するときに buildspec コマンドを無視します。ビルド中に buildspec コマンドを実行するには、サフィックスとして `buildspec-override:true` を `tags` に追加できます。
```
tags:
- codebuild--$CI_PROJECT_ID-$CI_PIPELINE_IID-$CI_JOB_NAME
- buildspec-override:true
```
このコマンドを使用すると、CodeBuild はコンテナのプライマリソースフォルダに `gitlab-runner` というフォルダを作成します。GitLab ランナーが `BUILD` フェーズ中に起動すると、ランナーはその `gitlab-runner` ディレクトリで実行されます。
セルフマネージド型 GitLab ビルドで buildspec の上書きを使用する場合、いくつかの制限があります。
+ CodeBuild は、セルフマネージド型ランナーが `BUILD` フェーズで実行されるため、`BUILD` フェーズ中は buildspec コマンドを実行しません。
+ CodeBuild は、`DOWNLOAD_SOURCE` フェーズ中はプライマリソースもセカンダリソースもダウンロードしません。buildspec ファイルが設定されている場合、プロジェクトのプライマリソースからそのファイルのみがダウンロードされます。
+ ビルドコマンドが `PRE_BUILD` または `INSTALL` フェーズで失敗した場合、CodeBuild はセルフマネージド型ランナーを起動せず、GitLab CI/CD パイプラインジョブは手動でキャンセルする必要があります。
+ CodeBuild は、`DOWNLOAD_SOURCE` フェーズ中にランナートークンを取得します。有効期限は 1 時間です。`PRE_BUILD` または `INSTALL` フェーズが 1 時間を超えると、GitLab セルフマネージド型ランナーが起動する前にランナートークンの有効期限が切れる可能性があります。
## ステップ 3: 結果を確認
GitLab CI/CD パイプラインの実行が発生するたびに、CodeBuild はウェブフックを介して CI/CD パイプラインジョブイベントを受信します。CI/CD パイプライン内のジョブごとに、CodeBuild はビルドを開始して一時的な GitLab ランナーを実行します。ランナーには、単一の CI/CD パイプラインジョブを実行する役割があります。ジョブが完了すると、ランナーおよび関連付けられたビルドプロセスは即座に終了します。
CI/CD パイプラインジョブのログを表示するには、GitLab のリポジトリに移動し、**[ビルド]**、**[ジョブ]** の順に選択し、ログを確認する特定の **[ジョブ]** を選択します。
ジョブが CodeBuild のセルフマネージド型ランナーによって取得されるのを待っている間に、リクエストされたラベルをログで確認できます。
## GitLab ウェブフックイベントのフィルタリング (CloudFormation)
CloudFormation テンプレートの次の YAML 形式の部分は、true と評価されたときにビルドをトリガーするフィルタグループを作成します。次のフィルタグループは、正規表現 `\[CI-CodeBuild\]` に一致する CI/CD パイプライン名を持つ GitLab CI/CD パイプラインジョブリクエストを指定します。
```
CodeBuildProject:
Type: AWS::CodeBuild::Project
Properties:
Name: MyProject
ServiceRole: service-role
Artifacts:
Type: NO_ARTIFACTS
Environment:
Type: LINUX_CONTAINER
ComputeType: BUILD_GENERAL1_SMALL
Image: aws/codebuild/standard:5.0
Source:
Type: GITLAB
Location: CODEBUILD_DEFAULT_WEBHOOK_SOURCE_LOCATION
Triggers:
Webhook: true
ScopeConfiguration:
Name: group-name
Scope: GITLAB_GROUP
FilterGroups:
- - Type: EVENT
Pattern: WORKFLOW_JOB_QUEUED
- Type: WORKFLOW_NAME
Pattern: \[CI-CodeBuild\]
```
# CodeBuild がホストする GitLab ランナーでサポートされているラベルの上書き
GitLab CI/CD パイプライン YAML では、セルフマネージド型ランナーのビルドを変更するさまざまなラベルの上書きを指定できます。CodeBuild で認識されないビルドは無視されますが、ウェブフックリクエストは失敗しません。例えば、次の YAML には、イメージ、インスタンスサイズ、フリート、および buildspec の上書きが含まれます。
```
workflow:
name: HelloWorld
stages:
- build
build-job:
stage: build
script:
- echo "Hello World!"
tags:
- codebuild-myProject-$CI_PROJECT_ID-$CI_PIPELINE_IID-$CI_JOB_NAME
- image:arm-3.0
- instance-size:small
- fleet:myFleet
- buildspec-override:true
```
`codebuild--$CI_PROJECT_ID-$CI_PIPELINE_IID-$CI_JOB_NAME` (必須)
+ 例: `codebuild-myProject-$CI_PROJECT_ID-$CI_PIPELINE_IID-$CI_JOB_NAME`
+ すべての GitLab CI/CD パイプライン YAML に必須です。** は、セルフマネージド型ランナーウェブフックが設定されているプロジェクトの名前と同じである必要があります。
`image:-`
+ 例: `image:arm-3.0`
+ セルフマネージド型ランナーのビルドの開始時に使用するイメージと環境タイプを上書きします。サポートされている値については、「[CodeBuild がホストする GitLab ランナーでサポートされているコンピューティングイメージ](sample-gitlab-runners-gitlab-ci.images.md)」を参照してください。
+ カスタムイメージで使用されるイメージと環境タイプを上書きするには、「`image:custom--`」を使用します。
+ 例: `image:custom-arm-public.ecr.aws/codebuild/amazonlinux-aarch64-standard:3.0`
**注記**
カスタムイメージがプライベートレジストリにある場合は、「[セルフホスト型ランナーのプライベートレジストリ認証情報を設定する](private-registry-sample-configure-runners.md)」を参照してください。
`instance-size:`
+ 例: `instance-size:small`
+ セルフマネージド型ランナーのビルドの開始時に使用するインスタンスタイプを上書きします。サポートされている値については、「[CodeBuild がホストする GitLab ランナーでサポートされているコンピューティングイメージ](sample-gitlab-runners-gitlab-ci.images.md)」を参照してください。
`fleet:`
+ 例: `fleet:myFleet`
+ 指定されたフリートを使用するために、プロジェクトに設定されたフリート設定を上書きします。詳細については、「[リザーブドキャパシティキャパシティフリートでビルドを実行](fleets.md)」を参照してください。
`buildspec-override:`
+ 例: `buildspec-override:true`
+ `true` に設定されている場合、ビルドが `INSTALL`、`PRE_BUILD`、および `POST_BUILD` フェーズで buildspec コマンドを実行できるようにします。
# CodeBuild がホストする GitLab ランナーでサポートされているコンピューティングイメージ
「[チュートリアル: CodeBuild がホストする GitLab ランナーを設定](sample-gitlab-runners.md)」で設定したラベルでは、最初の 3 つの列の値を使用して Amazon EC2 環境設定を上書きできます。CodeBuild では、次の Amazon EC2 コンピューティングイメージが用意されています。詳細については、以下を参照してください。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/sample-gitlab-runners-gitlab-ci.images.html)
さらに、次の値を使用して Lambda 環境設定を上書きできます。CodeBuild Lambda コンピューティングの詳細については、「[AWS Lambda コンピューティングでビルドを実行する](lambda.md)」を参照してください。CodeBuild は、次の Lambda コンピューティングイメージをサポートしています。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/sample-gitlab-runners-gitlab-ci.images.html)
詳細については、「[ビルド環境のコンピューティングモードおよびタイプ](build-env-ref-compute-types.md)」および「[CodeBuild に用意されている Docker イメージ](build-env-ref-available.md)」を参照してください。
# のセルフマネージド Buildkite ランナー AWS CodeBuild
CodeBuild コンテナにセルフホスト型 Buildkite ランナーを設定して、Buildkite ワークフロージョブを処理するようにプロジェクトを構成できます。これは、CodeBuild プロジェクトを使用してウェブフックを設定し、CodeBuild マシンでホストされているセルフホスト型ランナーを使用するように Buildkite パイプラインワークフロー YAML ステップを更新することによって実行できます。
Buildkite ジョブを実行するように CodeBuild プロジェクトを設定する大まかな手順は次のとおりです。
+ CodeBuild コンソールに移動し、Buildkite ランナープロジェクトのランナータイプ設定を使用して CodeBuild プロジェクトを作成します。
+ Buildkite 組織に `job.scheduled` ウェブフックを追加します。
+ Buildkite パイプラインの YAML ステップを更新して、ビルド環境を設定します。
より詳細な手順については、「[チュートリアル: CodeBuild がホストする Buildkite ランナーを設定](sample-runner-buildkite.md)」を参照してください。この機能を使用すると、Buildkite ジョブが とネイティブに統合され、IAM AWS、、 AWS Secrets Manager、Amazon VPC などの機能を通じてセキュリティ AWS CloudTrailと利便性が提供されます。ARM ベースのインスタンスなど、最新のインスタンスタイプにアクセスできます。
# CodeBuild がホストする Buildkite ランナーについて
以下は、CodeBuild がホストする Buildkite ランナーに関する、よくある質問です。
## ラベルにイメージとインスタンスの上書きを含める必要があるのはいつですか。
イメージとインスタンスの上書きをラベルに含めることで、Buildkite ジョブごとに異なるビルド環境を指定できます。これは、複数の CodeBuild プロジェクトやウェブフックを作成しなくても実行できます。例えば、[Buildkite ジョブにマトリックス](https://buildkite.com/docs/pipelines/configure/workflows/build-matrix)を使用する必要がある場合に便利です。
```
agents:
queue: "myQueue"
steps:
- command: "echo \"Hello World\""
agents:
project: "codebuild-myProject"
image: "{{matrix.os}}"
instance-size: "{{matrix.size}}"
matrix:
setup:
os:
- "arm-3.0"
- "al2-5.0"
size:
- "small"
- "large"
```
## CodeBuild は Buildkite 内にウェブフックを自動的に作成できますか?
現在のところ、Buildkite では、すべてのウェブフックをコンソールを使用して手動で作成する必要があります。「[チュートリアル: CodeBuild がホストする Buildkite ランナーを設定](sample-runner-buildkite.md)」のチュートリアルに従って、Buildkite コンソールで Buildkite ウェブフックを手動で作成することができます。
## CloudFormation を使用して Buildkite ウェブフックを作成できますか?
CloudFormation Buildkite ではコンソールを使用してウェブフックを手動で作成する必要があるため、 は現在 Buildkite ランナーウェブフックではサポートされていません。
## CodeBuild がホストする Buildkite ランナーの使用をサポートしているリージョンはどれですか?
CodeBuild がホストする Buildkite ランナーは、すべての CodeBuild リージョンでサポートされています。CodeBuild が利用可能な AWS リージョンの詳細については、[AWS 「リージョン別のサービス](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/)」を参照してください。
# チュートリアル: CodeBuild がホストする Buildkite ランナーを設定
このチュートリアルでは、CodeBuild プロジェクトを設定して Buildkite ジョブを実行する方法について説明します。CodeBuild で Buildkite を使用する方法の詳細については、「[のセルフマネージド Buildkite ランナー AWS CodeBuild](buildkite-runner.md)」を参照してください。
このチュートリアルを完了するには、まず以下を行う必要があります。
+ Buildkite 組織にアクセスできる。Buildkite アカウントと組織の設定の詳細については、この[入門チュートリアル](https://buildkite.com/docs/pipelines/getting-started)を参照してください。
+ セルフホスト型ランナーを使用するように設定された Buildkite パイプライン、クラスター、キューを作成する。これらのリソースをセットアップする方法の詳細については、「[Buildkite パイプラインセットアップチュートリアル](https://buildkite.com/docs/pipelines/create-your-own)」を参照してください。
![\[Buildkite でプロジェクトを構築する\]](http://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/images/buildkite-first.png)
## ステップ 1: Buildkite エージェントトークンを生成する
このステップでは、CodeBuild セルフホスト型ランナーの認証に使用されるエージェントトークンを Buildkite 内で生成します。このリソースの詳細については、「[Buildkite エージェントトークン](https://buildkite.com/docs/agent/v3/tokens)」を参照してください。
**Buildkite エージェントトークンを生成するには**
1. Buildkite クラスターで、**[エージェントトークン]** を選択し、**[新しいトークン]** を選択します。
1. トークンに説明を追加し、**[トークンを作成]** をクリックします。
1. エージェントトークン値は、後で CodeBuild プロジェクトのセットアップ中に使用するため、保存しておきます。
![\[Buildkite のエージェントトークン\]](http://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/images/buildkite-createtoken.png)
## ステップ 2: ウェブフックを使用して CodeBuild プロジェクトを作成する
**ウェブフックを使用して CodeBuild プロジェクトを作成するには**
1. [https://console.aws.amazon.com/codesuite/codebuild/home](https://console.aws.amazon.com/codesuite/codebuild/home) で AWS CodeBuild コンソールを開きます。
1. セルフホスト型ビルドプロジェクトを作成します。詳細については、「[ビルドプロジェクトの作成 (コンソール)](create-project.md#create-project-console)」および「[ビルドの実行 (コンソール)](run-build-console.md)」を参照してください。
+ **[プロジェクトの設定]** で、**[ランナープロジェクト]** を選択します。**[ランナー]** で、次のようにします。
+ **[ランナープロバイダー]** で、**[Buildkite]** を選択します。
+ **[Buildkite エージェントトークン]** で、**[シークレットの作成ページを使用して新しいエージェントトークンを作成する]** を選択します。で、上記で生成した Buildkite エージェントトークンと等しいシークレット値 AWS Secrets Manager を持つ新しいシークレットを作成するように求められます。
+ (オプション) ジョブに CodeBuild マネージド認証情報を使用する場合は、**[Buildkite ソース認証情報オプション]** でジョブのソースリポジトリプロバイダーを選択し、アカウントに認証情報が設定されていることを確認します。さらに、Buildkite パイプラインで **HTTPS を使用したチェックアウト**が使用されていることを確認します。
**注記**
ジョブのソースをプルするため、Buildkite によりビルド環境内でソース認証情報が求められます。使用可能なソース認証情報オプションについては、「[プライベートリポジトリへの Buildkite の認証](#sample-runner-buildkite-config)」を参照してください。
+ (オプション) **[環境]** で、次のようにします。
+ サポートされている **[環境イメージ]** と **[コンピューティング]** を選択します。
Buildkite YAML ステップのラベルを使用して、イメージとインスタンスの設定を上書きするオプションがあることに注意してください。詳細については、「[ステップ 4: Buildkite パイプラインステップを更新する](#sample-runner-buildkite-update-pipeline)」を参照してください。
+ (オプション) **[Buildspec]** で、次のようにします。
+ `buildspec-override: "true"` がラベルとして追加されない限り、buildspec は無視されます。代わりに、CodeBuild は、セルフホスト型ランナーを設定するコマンドを使用するように上書きします。
**注記**
CodeBuild は、Buildkite セルフホスト型ランナービルドの buildspec ファイルをサポートしていません。インライン buildspec の場合、CodeBuild マネージドソース認証情報を設定している場合は、buildspec で [git-credential-helper](https://docs.aws.amazon.com/codebuild/latest/userguide/build-spec-ref.html#build-spec.env.git-credential-helper) を有効にする必要があります。
1. デフォルト値のまま続行し、**[ビルドプロジェクトを作成する]** を選択します。
1. **[ウェブフックの作成]** ポップアップから **[ペイロードの URL]** と **[シークレット]** の値を保存します。ポップアップの手順に従って新しい Buildkite 組織のウェブフックを作成するか、次のセクションに進みます。
## ステップ 3: Buildkite 内で CodeBuild ウェブフックを作成する
このステップでは、CodeBuild ウェブフックの **[ペイロード URL]** と **[シークレット]** の値を使用して、Buildkite 内に新しいウェブフックを作成します。このウェブフックは、有効な Buildkite ジョブの開始時に CodeBuild 内でビルドをトリガーするために使用されます。
**Buildkite で新しいウェブフックを作成するには**
1. Buildkite 組織の **[設定]** ページに移動します。
1. **[統合]** で、**[通知サービス]** を選択します。
1. **[ウェブフック]** ボックスの横にある **[追加]** を選択します。**[ウェブフック通知の追加]** ページで、次の設定を使用します。
1. **[ウェブフックの URL]** で、保存された **[ペイロードの URL]** 値を追加します。
1. **[トークン]** で、**[X-Buildkite-Token としてトークンを送信]** が選択されていることを確認します。ウェブフックの **[シークレット]** 値を **[トークン]** フィールドに追加します。
1. **[X-Buildkite-Token としてトークンを送信]** が選択されていることを確認します。ウェブフックの **[シークレット]** 値を **[トークン]** フィールドに追加します。
1. **[イベント]** で、`job.scheduled` ウェブフックイベントを選択します。
1. (オプション) **[パイプライン]** では、オプションで特定のパイプラインのビルドのみをトリガーするように選択できます。
1. **[ウェブフック通知の追加]** を選択します。
## ステップ 4: Buildkite パイプラインステップを更新する
このステップでは、Buildkite パイプラインのステップを更新して、必要なラベルとオプションの上書きを追加します。サポートされているラベル上書きの詳細なリストについては、「[CodeBuild がホストする Buildkite ランナーでサポートされているラベルの上書き](buildkite-runner-update-labels.md)」を参照してください。
**パイプラインステップを更新する**
1. Buildkite パイプラインを選択して、**[設定]** を選択し、**[ステップ]** を選択して、Buildkite パイプラインステップページに移動します。
まだの場合は、**[YAML ステップに変換]** を選択します。
![\[YAML を更新するステップ。\]](http://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/images/buildkite-steps.png)
1. 少なくとも、CodeBuild パイプラインの名前を参照する [Buildkite エージェントタグ](https://buildkite.com/docs/agent/v3/cli-start#agent-targeting)を指定する必要があります。Buildkite ジョブの AWS関連設定を特定の CodeBuild プロジェクトにリンクするには、プロジェクト名が必要です。YAML にプロジェクト名を含めることで、CodeBuild は正しいプロジェクト設定でジョブを呼び出すことができます。
```
agents:
project: "codebuild-"
```
以下は、プロジェクトラベルタグのみを含む Buildkite パイプラインステップの例です。
```
agents:
project: "codebuild-myProject"
steps:
- command: "echo \"Hello World\""
```
ラベル内のイメージとコンピューティングタイプを上書きすることもできます。使用可能なイメージのリストについては、「[CodeBuild がホストする Buildkite ランナーでサポートされているコンピューティングイメージ](buildkite-runner-update-yaml.images.md)」を参照してください。ラベル内のコンピューティングタイプとイメージは、プロジェクトの環境設定を上書きします。CodeBuild EC2 または Lambda コンピューティングビルドの環境設定を上書きするには、次の構文を使用します。
```
agents:
project: "codebuild-"
image: "-"
instance-size: ""
```
イメージサイズとインスタンスサイズの上書きを含む Buildkite パイプラインステップの例を次に示します。
```
agents:
project: "codebuild-myProject"
image: "arm-3.0"
instance-size: "small"
steps:
- command: "echo \"Hello World\""
```
ラベル内のビルドに使用するフリートを上書きできます。これにより、プロジェクトで設定されたフリート設定が上書きされ、指定されたフリートが使用されます。詳細については、「[リザーブドキャパシティフリートでビルドを実行](https://docs.aws.amazon.com/codebuild/latest/userguide/fleets.html)」を参照してください。
Amazon EC2 コンピューティングビルドのフリート設定を上書きするには、次の構文を使用します。
```
agents:
project: "codebuild-"
fleet: ""
```
ビルドに使用されるフリートとイメージの両方を上書きするには、次の構文を使用します。
```
agents:
project: "codebuild-"
fleet: ""
image: "-"
```
フリートとイメージの上書きを含む Buildkite パイプラインステップの例を次に示します。
```
agents:
project: "codebuild-myProject"
fleet: "myFleet"
image: "arm-3.0"
steps:
- command: "echo \"Hello World\""
```
1. セルフホスト型 Buildkite ランナーのビルド中にインライン buildspec コマンドを実行することを選択できます (詳細については、「[INSTALL、PRE\$1BUILD、POST\$1BUILD フェーズで buildspec コマンドを実行](sample-runner-buildkite-buildspec.md)」を参照してください)。Buildkite セルフホスト型ランナーのビルド中に CodeBuild ビルドが buildspec コマンドを実行するように指定するには、次の構文を使用します。
```
agents:
project: "codebuild-"
buildspec-override: "true"
```
buildspec の上書きを使用する Buildkite パイプラインの例を次に示します。
```
agents:
project: "codebuild-myProject"
buildspec-override: "true"
steps:
- command: "echo \"Hello World\""
```
1. 必要に応じて、CodeBuild がサポートするラベル以外のラベルを提供できます。これらのラベルは、ビルドの属性を上書きする目的で無視されますが、ウェブフックリクエストは失敗しません。例えば、`myLabel: “testLabel"` をラベルとして追加しても、ビルドの実行は妨げられません。
## ステップ 5: 結果を確認する
Buildkite ジョブがパイプラインで開始されるたびに、CodeBuild は Buildkite ウェブフックを介して `job.scheduled` ウェブフックイベントを受け取ります。Buildkite ビルド内のジョブごとに、CodeBuild はエフェメラル Buildkite ランナーを実行するビルドを開始します。ランナーには、単一の Buildkite ジョブを実行する役割があります。ジョブが完了すると、ランナーおよび関連付けられたビルドプロセスは即座に終了します。
ワークフロージョブログを表示するには、Buildkite パイプラインに移動し、最新のビルドを選択します (**[新しいビルド]** を選択して新しいビルドをトリガーできます)。各ジョブに関連付けられた CodeBuild ビルドが開始されてジョブが取得されると、Buildkite コンソールにジョブのログが表示されます。
![\[結果を確認します。\]](http://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/images/buildkite-log.png)
## プライベートリポジトリへの Buildkite の認証
Buildkite パイプライン内にプライベートリポジトリが設定されている場合、Buildkite はプライベートリポジトリからプルするためにセルフホスト型ランナーに認証情報を供給しないため、Buildkite はリポジトリをプルするために[ビルド環境内で追加のアクセス許可](https://buildkite.com/docs/agent/v3/github-ssh-keys)を必要とします。Buildkite セルフホスト型ランナーエージェントを外部プライベートソースリポジトリに対して認証するには、次のいずれかのオプションを使用できます。
**CodeBuild で認証するには**
CodeBuild は、サポートされているソースタイプのマネージド認証情報処理を行います。CodeBuild ソース認証情報を使用してジョブのソースリポジトリをプルするには、次の手順を使用します。
1. CodeBuild コンソールで、**[プロジェクトの編集]** に移動するか、「[ステップ 2: ウェブフックを使用して CodeBuild プロジェクトを作成する](#sample-runner-buildkite-create-project)」のステップを使用して新しい CodeBuild プロジェクトを作成します。
1. **[Buildkite ソース認証情報オプション]** で、ジョブのソースリポジトリプロバイダーを選択します。
1. アカウントレベルの CodeBuild 認証情報を使用する場合は、それらが正しく設定されていることを確認します。さらに、プロジェクトにインライン buildspec が設定されている場合は、[git-credential-helper](https://docs.aws.amazon.com/codebuild/latest/userguide/build-spec-ref.html#build-spec.env.git-credential-helper) が有効になっていることを確認します。
1. プロジェクトレベルの CodeBuild 認証情報を使用する場合は、**[このプロジェクトの上書き認証情報のみを使用する]** を選択し、プロジェクトの認証情報を設定します。
1. Buildkite パイプライン設定で、**[リポジトリの設定]** に移動します。ソースリポジトリのチェックアウト設定を **[HTTPS を使用してチェックアウト]** に設定する
![\[結果を確認します。\]](http://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/images/buildkite-repo-https.png)
**Buildkite シークレットで認証するには**
Buildkite には、ssh キーを使用して外部ソースリポジトリに対してセルフホスト型ランナーを認証するために使用できる [ssh-checkout プラグイン](https://github.com/buildkite-plugins/git-ssh-checkout-buildkite-plugin)が維持されます。キー値は [Buildkite シークレット](https://buildkite.com/docs/pipelines/security/secrets/buildkite-secrets)として保存され、プライベートリポジトリをプルしようとすると Buildkite セルフホスト型ランナーエージェントによって自動的に取得されます。Buildkite パイプラインの ssh-checkout プラグインを設定するには、次のステップを使用します。
1. E メールアドレスを使用してプライベートおよびパブリック SSH キーを生成します。例: `ssh-keygen -t rsa -b 4096 -C "myEmail@address.com"`
1. パブリックキーをプライベートソースリポジトリに追加します。例えば、[このガイド](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/adding-a-new-ssh-key-to-your-github-account)に従って GitHub アカウントにキーを追加できます。
1. Buildkite クラスターに[新しい SSH キーシークレット](https://buildkite.com/docs/pipelines/hosted-agents/code-access#private-repositories-with-other-providers-add-the-ssh-key-secret)を追加します。Buildkite クラスター内で、**[シークレット]** → **[新しいシークレット]** を選択します。**[キー]** フィールドにシークレットの名前を追加し、**[値]** フィールドにプライベート SSH キーを追加します。
![\[結果を確認します。\]](http://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/images/buildkite-secret.png)
1. Buildkite パイプライン内で、リポジトリ設定に移動し、**SSH** を使用するようにチェックアウトを設定します。
![\[結果を確認します。\]](http://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/images/buildkite-repo.png)
1. パイプラインの YAML ステップを更新して、`git-ssh-checkout` プラグインを使用します。たとえば、次のパイプライン YAML ファイルでは、上記の Buildkite シークレットキーを使用してチェックアウトアクションを使用します。
```
agents:
project: "codebuild-myProject"
steps:
- command: "npm run build"
plugins:
- git-ssh-checkout#v0.4.1:
ssh-secret-key-name: 'SOURCE_SSH_KEY'
```
1. CodeBuild 内で Buildkite セルフホスト型ランナージョブを実行すると、プライベートリポジトリをプルするときに、設定されたシークレット値が Buildkite により自動的に使用されるようになりました。
## ランナー設定オプション
プロジェクト設定で次の環境変数を指定して、セルフホスト型ランナーのセットアップ設定を変更できます。
+ `CODEBUILD_CONFIG_BUILDKITE_AGENT_TOKEN`: CodeBuild は、Buildkite セルフホスト型ランナーエージェントを登録するために、この環境変数の値として設定されたシークレット値を AWS Secrets Manager から取得します。この環境変数はタイプ `SECRETS_MANAGER` でなければならず、値は Secrets Manager のシークレットの名前である必要があります。Buildkite エージェントトークン環境変数は、すべての Buildkite ランナープロジェクトに必要です。
+ `CODEBUILD_CONFIG_BUILDKITE_CREDENTIAL_DISABLE`: デフォルトでは、CodeBuild はアカウントまたはプロジェクトレベルのソース認証情報をビルド環境にロードします。これらの認証情報は、Buildkite エージェントによってジョブのソースリポジトリをプルするために使用されます。この動作を無効にするには、値を `true` に設定してこの環境変数をプロジェクトに追加します。これにより、ソース認証情報がビルド環境にロードされなくなります。
# INSTALL、PRE\$1BUILD、POST\$1BUILD フェーズで buildspec コマンドを実行
デフォルトでは、CodeBuild はセルフホスト型 Buildkite ランナービルドを実行するときに buildspec コマンドを無視します。ビルド中に buildspec コマンドを実行するには、
```
buildspec-override: "true"
```
を、ラベルのサフィックスとして追加します。
```
agents:
project: "codebuild-"
buildspec-override: "true"
```
このコマンドを使用すると、CodeBuild はコンテナのプライマリソースフォルダに `buildkite-runner` というフォルダを作成します。Buildkite ランナーが `BUILD` フェーズ中に起動すると、ランナーはその `buildkite-runner` ディレクトリで実行されます。
セルフホスト型 Buildkite ビルドで buildspec の上書きを使用する場合、いくつかの制限があります。
+ Buildkite エージェントでは、ジョブのソースリポジトリをプルするために、ソース認証情報がビルド環境内に存在する必要があります。認証に CodeBuild ソース認証情報を使用する場合は、buildspec で `git-credential-helper` を有効にする必要があります。例えば、次の buildspec を使用して Buildkite ビルドで `git-credential-helper` を有効にできます。
```
version: 0.2
env:
git-credential-helper: yes
phases:
pre_build:
commands:
- echo "Hello World"
```
+ CodeBuild は、セルフホスト型ランナーが `BUILD` フェーズで実行されるため、`BUILD` フェーズ中は buildspec コマンドを実行しません。
+ CodeBuild は、Buildkite ランナービルドの buildspec ファイルをサポートしていません。Buildlkite セルフホスト型ランナーでは、インライン buildspec のみがサポートされます
+ ビルドコマンドが `PRE_BUILD` または `INSTALL` フェーズで失敗した場合、CodeBuild はセルフホスト型ランナーを起動せず、Buildkite ジョブは手動でキャンセルする必要があります。
# Buildkite ランナーをプログラムによりセットアップする
Buildkite ランナープロジェクトをプログラムにより設定するには、次のリソースを設定する必要があります。
**Buildkite ランナーをプログラムにより作成するには**
1. Buildkite エージェントトークンを作成し、トークンを AWS Secrets Manager内にプレーンテキストで保存します。
1. 任意の設定で CodeBuild プロジェクトをセットアップします。次の追加属性を設定する必要があります。
1. `CODEBUILD_CONFIG_BUILDKITE_AGENT_TOKEN` という名前の環境値、タイプ `SECRETS_MANAGER`、および Buildkite クラスターに関連付けられた Buildkite エージェントトークンと等しい値。
1. `NO_SOURCE` と等しいソースタイプ
1. プロジェクトのサービスロールのステップ 1 で作成したシークレットにアクセスするためのアクセス許可
例えば、CLI で次のコマンドを使用して有効な Buildkite ランナープロジェクトを作成できます。
```
aws codebuild create-project \
--name buildkite-runner-project \
--source "{\"type\": \"NO_SOURCE\",\"buildspec\":\"\"}" \
--environment "{\"image\":\"aws/codebuild/amazonlinux-x86_64-standard:5.0\",\"type\":\"LINUX_CONTAINER\",\"computeType\":\"BUILD_GENERAL1_MEDIUM\",\"environmentVariables\":[{\"name\":\"CODEBUILD_CONFIG_BUILDKITE_AGENT_TOKEN\",\"type\":\"SECRETS_MANAGER\",\"value\":\"\"}]}" \
--artifacts "{\"type\": \"NO_ARTIFACTS\"}" \
--service-role
```
1. ステップ 2 で作成したプロジェクトに Buildkite ランナーウェブフックを作成します。ウェブフックを作成するときは、次の設定オプションを使用する必要があります。
1. **build-type** は `RUNNER_BUILDKITE_BUILD` と等しくなければなりません
1. タイプが `EVENT` でパターンが `WORKFLOW_JOB_QUEUED` に等しいフィルター
例えば、CLI で次のコマンドを使用して有効な Buildkite ランナーウェブフックを作成できます。
```
aws codebuild create-webhook \
--project-name buildkite-runner-project \
--filter-groups "[[{\"type\":\"EVENT\",\"pattern\":\"WORKFLOW_JOB_QUEUED\"}]]" \
--build-type RUNNER_BUILDKITE_BUILD
```
1. `create-webhook` 呼び出しによって返された **[ペイロード URL]** と **[シークレット]** の値を保存し、認証情報を使用して Buildkite コンソール内にウェブフックを作成します。このリソースのセットアップ方法については、「[チュートリアル: CodeBuild がホストする Buildkite ランナーを設定](sample-runner-buildkite.md)」の「ステップ 3: Buildkite 内で CodeBuild ウェブフックを作成する」を参照してください。
# 失敗したビルドまたはハングしたジョブのウェブフックのトラブルシューティング
**問題: **
問題: [チュートリアル: CodeBuild がホストする Buildkite ランナーを設定](sample-runner-buildkite.md) でセットアップしたウェブフックが機能していないか、ワークフロージョブが Buildkite でハングしています。
**考えられる原因: **
+ ウェブフックの **job.scheduled** イベントがビルドのトリガーに失敗している可能性があります。**[レスポンス]** ログを確認して、レスポンスまたはエラーメッセージを表示します。
+ Buildkite セルフホスト型ランナーエージェントを開始してジョブを処理する前に、CodeBuild ビルドが失敗します。
**推奨される解決策: **
失敗した Buildkite ウェブフックイベントをデバッグするには、次のようにします。
1. Buildkite 組織設定で、**[通知サービス]** に移動し、CodeBuild ウェブフックを選択して **[リクエストログ]** を見つけます。
1. スタックした Buildkite ジョブに関連付けられた `job.scheduled` ウェブフックイベントを見つけます。ウェブフックペイロード内のジョブ ID フィールドを使用して、ウェブフックイベントを Buildkite ジョブに関連付けることができます。
1. **[レスポンス]** タブを選択し、レスポンス本文を確認します。**[レスポンス]** ステータスコードが `200` であり、**[レスポンス]** 本文に予期しないメッセージが含まれていないことを確認します。
![\[ウェブフックのレスポンス。\]](http://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/images/buildkite-request.png)
# ウェブフックのアクセス許可に関する問題のトラブルシューティング
**問題: **
アクセス許可に問題があるため、Buildkite ジョブはジョブのソースリポジトリのチェックアウトに失敗します。
**考えられる原因: **
+ CodeBuild に、ジョブのソースリポジトリをチェックアウトするための十分なアクセス許可がありません。
+ パイプラインのリポジトリ設定が、CodeBuild マネージド認証情報の SSH を使用してチェックアウトするように設定されています。
**推奨される解決策: **
+ CodeBuild に、ジョブのソースリポジトリをチェックアウトするための十分なアクセス許可が設定されていることを確認します。さらに、CodeBuild プロジェクトのサービスロールに、設定されたソースアクセス許可オプションにアクセスするための十分なアクセス許可があることを確認します。
+ CodeBuild マネージドソースリポジトリ認証情報を使用している場合は、HTTPS を使用してチェックアウトを使用するように Buildkite パイプラインが設定されていることを確認します。
# CodeBuild がホストする Buildkite ランナーでサポートされているラベルの上書き
Buildkite パイプラインステップのエージェントタグラベルでは、セルフマネージド型ランナーのビルドを変更するさまざまなラベルの上書きを指定できます。CodeBuild で認識されないビルドは無視されますが、ウェブフックリクエストは失敗しません。例えば、次のワークフロー YAML には、イメージ、インスタンスサイズ、フリート、および buildspec の上書きが含まれます。
```
agents:
queue: "myQueue"
steps:
- command: "echo \"Hello World\""
agents:
project: "codebuild-myProject"
image: "{{matrix.os}}"
instance-size: "{{matrix.size}}"
buildspec-override: "true"
matrix:
setup:
os:
- "arm-3.0"
- "al2-5.0"
size:
- "small"
- "large"
```
`project:codebuild-` (必須)
+ 例: `project: "codebuild-myProject"`
+ すべての Buildkite パイプラインステップ設定に必須です。** は、セルフホスト型ランナーウェブフックが設定されているプロジェクトの名前と同じである必要があります。
`queue: ""`
+ 例: `queue: ""`
+ Buildkite ジョブを特定のキューにルーティングするために使用されます。詳細については、「[Buildkite エージェントキュータグ](https://buildkite.com/docs/agent/v3/cli-start#the-queue-tag)」を参照してください。
`image: "-"`
+ 例: `image: "arm-3.0"`
+ 選別されたイメージを使用したセルフホスト型ランナーのビルドの開始時に使用するイメージと環境タイプを上書きします。サポートされている値については、「[CodeBuild がホストする Buildkite ランナーでサポートされているコンピューティングイメージ](buildkite-runner-update-yaml.images.md)」を参照してください。
1. カスタムイメージで使用されるイメージと環境タイプを上書きするには、「`image: "custom--"`」を使用します。
1. 例:
```
image:
"custom-arm-public.ecr.aws/codebuild/amazonlinux-aarch64-standard:3.0"
```
**注記**
カスタムイメージがプライベートレジストリに存在する場合は、CodeBuild プロジェクトで適切なレジストリ認証情報を設定する必要があります。
`instance-size: ""`
+ 例: `instance-size: "medium"`
+ セルフホスト型ランナーのビルドの開始時に使用するインスタンスタイプを上書きします。サポートされている値については、「[CodeBuild がホストする Buildkite ランナーでサポートされているコンピューティングイメージ](buildkite-runner-update-yaml.images.md)」を参照してください。
`fleet: ""`
+ 例: `fleet: "myFleet"`
+ 指定されたフリートを使用するために、プロジェクトに設定されたフリート設定を上書きします。詳細については、「[リザーブドキャパシティフリートでビルドを実行](https://docs.aws.amazon.com/codebuild/latest/userguide/fleets.html)」を参照してください。
`buildspec-override: ""`
+ 例: `buildspec-override: "true"`
+ `true` に設定されている場合、ビルドが `INSTALL`、`PRE_BUILD`、および `POST_BUILD` フェーズで buildspec コマンドを実行できるようにします。
# CodeBuild がホストする Buildkite ランナーでサポートされているコンピューティングイメージ
「[のセルフマネージド Buildkite ランナー AWS CodeBuild](buildkite-runner.md)」で設定したラベルでは、最初の 3 つの列の値を使用して Amazon EC2 環境設定を上書きできます。CodeBuild では、次の Amazon EC2 コンピューティングイメージが用意されています。詳細については、以下を参照してください。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/buildkite-runner-update-yaml.images.html)
さらに、次の値を使用して Lambda 環境設定を上書きできます。CodeBuild Lambda コンピューティングの詳細については、「[AWS Lambda コンピューティングでビルドを実行する](lambda.md)」を参照してください。CodeBuild は、次の Lambda コンピューティングイメージをサポートしています。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/buildkite-runner-update-yaml.images.html)
詳細については、「[ビルド環境のコンピューティングモードおよびタイプ](build-env-ref-compute-types.md)」および「[CodeBuild に用意されている Docker イメージ](build-env-ref-available.md)」を参照してください。
# でウェブフックを使用する AWS CodeBuild
AWS CodeBuild は、GitHub、GitHub Enterprise Server、GitLab、GitLab Self Managed、Bitbucket とのウェブフック統合をサポートしています。
**Topics**
+ [
## でウェブフックを使用するためのベストプラクティス AWS CodeBuild
](#webhook-best-practices)
+ [
# Bitbucket ウェブフックイベント
](bitbucket-webhook.md)
+ [
# GitHub グローバルおよび組織のウェブフック
](github-global-organization-webhook.md)
+ [
# GitHub 手動ウェブフック
](github-manual-webhook.md)
+ [
# GitHub ウェブフックイベント
](github-webhook.md)
+ [
# GitLab グループウェブフック
](gitlab-group-webhook.md)
+ [
# GitLab 手動ウェブフック
](gitlab-manual-webhook.md)
+ [
# GitLab ウェブフックイベント
](gitlab-webhook.md)
+ [
# Buildkite 手動ウェブフック
](buildkite-manual-webhook.md)
+ [
# プルリクエストコメントの承認
](pull-request-build-policy.md)
## でウェブフックを使用するためのベストプラクティス AWS CodeBuild
パブリックリポジトリを使用してウェブフックをセットアップするプロジェクトでは、以下のオプションを使用することをお勧めします。
`ACTOR_ACCOUNT_ID` フィルタを設定
プロジェクトのウェブフックフィルタグループに `ACTOR_ACCOUNT_ID` フィルタを追加して、ビルドをトリガーできるユーザーを指定します。CodeBuild に配信されるすべてのウェブフックイベントには、アクターの識別子を指定する送信者情報が含まれています。CodeBuild は、フィルタで提供される正規表現パターンに基づいてウェブフックをフィルタリングします。このフィルタを使用して、ビルドのトリガーを許可する特定のユーザーを指定できます。詳細については、「[GitHub ウェブフックイベント](github-webhook.md)」および「[Bitbucket ウェブフックイベント](bitbucket-webhook.md)」を参照してください。
`FILE_PATH` フィルタを設定
プロジェクトのウェブフックフィルタグループに `FILE_PATH` フィルタを追加して、変更時にビルドをトリガーできるファイルを含めるか除外します。例えば、`^buildspec.yml$` などの正規表現パターンを `excludeMatchedPattern` プロパティと使用して、`buildspec.yml` ファイルへの変更に対するビルドリクエストを拒否できます。詳細については、「[GitHub ウェブフックイベント](github-webhook.md)」および「[Bitbucket ウェブフックイベント](bitbucket-webhook.md)」を参照してください。
ビルドの IAM ロールのアクセス権限を絞り込む
Webhook によってトリガーされたビルドは、プロジェクトで指定された IAM サービスロールを使用します。サービスロールのアクセス許可は、ビルドの実行に必要な最小限のアクセス許可セットに設定することをお勧めします。たとえば、テストおよびデプロイのシナリオでは、テスト用にプロジェクトを 1 つ作成し、デプロイ用に別のプロジェクトを作成します。テストプロジェクトは、リポジトリからの webhook ビルドを受け付けますが、リソースへの書き込み権限は提供しません。デプロイメントプロジェクトはリソースへの書き込み権限を提供し、webhook フィルターは信頼済みのユーザーにのみビルドをトリガーできるように設定されています。
インラインまたは Amazon S3 に保管した buildspec を使用する
プロジェクト自体内で buildspec をインラインで定義する場合、または buildspec ファイルを Amazon S3 バケットに格納する場合、buildspec ファイルはプロジェクト所有者のみに表示されます。これにより、プル要求が buildspec ファイルにコードを変更したり、不要なビルドをトリガーしたりするのを防ぎます。詳細については、「*CodeBuild API リファレンス*」の「[ProjectSource.buildspec](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_ProjectSource.html#CodeBuild-Type-ProjectSource-buildspec)」を参照してください。
# Bitbucket ウェブフックイベント
Webhook フィルタグループを使用して、ビルドをトリガーする Bitbucket ウェブフックイベントを指定できます。たとえば、特定のブランチへの変更に対してのみビルドをトリガーするように指定できます。
ビルドをトリガーするウェブフックイベントを指定するには、ウェブフックフィルタグループを 1 つ以上作成できます。任意のフィルターグループが true と評価されると、ビルドがトリガーされます。これは、グループ内のすべてのフィルターが true と評価されたときに発生します。フィルタグループを作成する際、以下を指定します。
**イベント**
Bitbucket では、次のイベントのうち、1 つ以上を選択できます:
+ `PUSH`
+ `PULL_REQUEST_CREATED`
+ `PULL_REQUEST_UPDATED`
+ `PULL_REQUEST_MERGED`
+ `PULL_REQUEST_CLOSED`
ウェブフックのイベントタイプは、`X-Event-Key` フィールドのヘッダーに含まれています。次の表に、`X-Event-Key` ヘッダー値がイベントタイプにマッピングされる方法を示します。
`PULL_REQUEST_MERGED` イベントタイプを使用するウェブフックフィルタグループを作成する場合は、Bitbucket ウェブフック設定で `merged` イベントを有効にする必要があります。`PULL_REQUEST_CLOSED` イベントタイプを使用するウェブフックフィルタグループを作成する場合は、Bitbucket ウェブフック設定で `declined` イベントも有効にする必要があります。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/bitbucket-webhook.html)
`PULL_REQUEST_MERGED` の場合、プルリクエストがスカッシュ戦略とマージされ、プルリクエストブランチが閉じられると、元のプルリクエストコミットは存在しなくなります。この場合、`CODEBUILD_WEBHOOK_MERGE_COMMIT` 環境変数には、圧縮されたマージコミットの識別子が含まれます。
**1 つ以上のオプションフィルタ**
フィルタを指定するには、正規表現を使用します。ビルドをトリガーするイベントでは、関連付けられているグループ内のすべてのフィルターが true と評価される必要があります。
`ACTOR_ACCOUNT_ID` (コンソール内の `ACTOR_ID`)
Bitbucket アカウント ID が正規表現パターンと一致すると、ビルドがウェブフックイベントでトリガーされます。この値は、ウェブフックフィルタペイロードの `actor` オブジェクトの `account_id` プロパティに表示されます。
`HEAD_REF`
ヘッドリファレンスが正規表現パターンと一致すると (`refs/heads/branch-name` と `refs/tags/tag-name` など)、ウェブフックイベントによってビルドがトリガーされます。`HEAD_REF` フィルタは、ブランチまたはタグについて Git 参照名を評価します。ブランチ名またはタグ名は、ウェブフックペイロードの `push` オブジェクトにある、`new` オブジェクトの `name` フィールドに表示されます。プルリクエストイベントの場合、ブランチ名はウェブフックペイロードの `source` オブジェクトにある、`branch` オブジェクトの `name` フィールドに表示されます。
`BASE_REF`
基本参照が正規表現パターンと一致すると、ビルドがウェブフックイベントでトリガーされます。`BASE_REF` フィルタは、プルリクエストイベントでのみ使用できます (例: `refs/heads/branch-name`)。`BASE_REF` フィルタは、ブランチの Git 参照名を評価します。ブランチ名は、ウェブフックペイロードの `destination` オブジェクトにある、`branch` オブジェクトの `name` フィールドに表示されます。
`FILE_PATH`
変更されたファイルのパスが正規表現パターンに一致すると、ビルドが Webhook イベントでトリガーされます。
`COMMIT_MESSAGE`
HEAD コミットメッセージが正規表現パターンに一致する場合に、Webhook はビルドをトリガーします。
`WORKFLOW_NAME`
ワークフロー名が正規表現パターンに一致する場合に、ウェブフックはビルドをトリガーします。
**注記**
ウェブフックペイロードは、Bitbucket リポジトリのウェブフック設定で見つかります。
**Topics**
+ [
# Bitbucket ウェブフックイベントのフィルタリング (コンソール)
](bitbucket-webhook-events-console.md)
+ [
# Bitbucket ウェブフックイベントのフィルタリング (SDK)
](bitbucket-webhook-events-sdk.md)
+ [
# Bitbucket ウェブフックイベントのフィルタリング (CloudFormation)
](bitbucket-webhook-events-cfn.md)
# Bitbucket ウェブフックイベントのフィルタリング (コンソール)
を使用してウェブフックイベント AWS マネジメントコンソール をフィルタリングするには:
1. プロジェクトの作成時に [**コードの変更がこのレポジトリにプッシュされるたびに再構築する**] を選択します。
1. [**イベントタイプ**] から、1 つ以上のイベントを選択します。
1. イベントでビルドをトリガーされた時間をフィルタリングするには、[**これらの条件でビルドを開始する**] で、1 つ以上のオプションフィルタを追加します。
1. イベントがトリガーされていない時間をフィルタリングするには、[**これらの条件でビルドを開始しない**] で、1 つ以上のオプションフィルタを追加します。
1. 別のフィルタグループを追加するには、[**フィルタグループの追加**] を選択します。
詳細については、「*AWS CodeBuild API リファレンス*」の「[ビルドプロジェクトの作成 (コンソール)](create-project.md#create-project-console)」および「[WebhookFilter](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_WebhookFilter.html)」を参照してください。
この例では、ウェブフックフィルタグループは、プルリクエストに対してのみビルドをトリガーします。
![\[プルリクエストのみのビルドをトリガーするウェブフックフィルタグループ。\]](http://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/images/pull-request-webhook-filter-bitbucket.png)
2 つのフィルタグループの例を使用した場合、ビルドは一方または両方が true と評価されるとトリガーされます。
+ 最初のフィルタグループでは、正規表現 `^refs/heads/main$` に一致する Git 参照と `^refs/heads/branch1!` に一致するヘッド参照を含むブランチで作成または更新されたプルリクエストを指定します。
+ 2 番目のフィルタグループでは、正規表現 `^refs/heads/branch1$` に一致する Git 参照を含むブランチでプッシュリクエストを指定します。
![\[2 つのフィルタグループの例です。\]](http://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/images/pull-request-webhook-filter-head-base-regexes-bitbucket.png)
この例では、ウェブフックフィルタグループは、タグイベントを除くすべてのリクエストに対してビルドをトリガーします。
![\[タグイベントを除くすべてのリクエストに対してビルドをトリガーする、ウェブフックフィルタグループです。\]](http://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/images/pull-request-webhook-filter-exclude-bitbucket.png)
この例では、ウェブフックフィルタグループは、正規表現 `^buildspec.*` に一致する名前のファイルが変更された場合にのみビルドをトリガーします。
![\[指定された正規表現に一致する名前のファイルに対してのみビルドをトリガーする、ウェブフックフィルタグループです。\]](http://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/images/pull-request-webhook-filter-file-name-regex.png)
この例で、Webhook フィルターグループは、ファイルが `src` または `test` フォルダーで変更された場合にのみ、ビルドをトリガーします。
![\[指定されたフォルダ内でファイルが変更された場合にのみビルドをトリガーするウェブフックフィルタグループです。\]](http://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/images/pull-request-webhook-filter-file-name-combined-regex.png)
この例では、正規表現 `actor-account-id` と一致するアカウント ID を持たない Bitbucket ユーザーが変更を行った場合にのみ、ウェブフックフィルタグループがビルドをトリガーします。
**注記**
Bitbucket アカウント ID の検索方法については、「https://api.bitbucket.org/2.0/users/*user-name*」を参照してください。ここで、*user-name* は、Bitbucket のユーザー名を表します。
![\[アカウント ID を持たない Bitbucket ユーザーが変更を行った場合にのみビルドをトリガーするウェブフックフィルタグループです。\]](http://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/images/pull-request-webhook-filter-actor-bitbucket.png)
この例では、HEAD コミットメッセージが正規表現 `\[CodeBuild\]` に一致する場合に、Webhook フィルタグループがプッシュイベントのビルドをトリガーします。
![\[HEAD コミットメッセージが正規表現に一致する場合に、プッシュイベントのビルドをトリガーするウェブフックフィルタグループです。\]](http://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/images/pull-request-webhook-filter-commit-message.png)
# Bitbucket ウェブフックイベントのフィルタリング (SDK)
AWS CodeBuild SDK を使用してウェブフックイベントをフィルタリングするには、 `CreateWebhook`または `UpdateWebhook` API メソッドのリクエスト構文で `filterGroups`フィールドを使用します。詳細については、*CodeBuild API リファレンス*の「[WebhookFilter](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_WebhookFilter.html)」を参照してください。
プルリクエストに対してのみビルドをトリガーするウェブフックフィルタを作成するには、以下をリクエスト構文に挿入します。
```
"filterGroups": [
[
{
"type": "EVENT",
"pattern": "PULL_REQUEST_CREATED, PULL_REQUEST_UPDATED, PULL_REQUEST_MERGED, PULL_REQUEST_CLOSED"
}
]
]
```
指定されたブランチに対してのみビルドをトリガーするウェブフックフィルタを作成するには、`pattern` パラメータを使用して、ブランチ名をフィルタリングするよう正規表現を指定します。2 つのフィルタグループの例を使用した場合、ビルドは一方または両方が true と評価されるとトリガーされます。
+ 最初のフィルタグループでは、正規表現 `^refs/heads/main$` に一致する Git 参照と `^refs/heads/myBranch$` に一致するヘッド参照を含むブランチで作成または更新されたプルリクエストを指定します。
+ 2 番目のフィルタグループでは、正規表現 `^refs/heads/myBranch$` に一致する Git 参照を含むブランチでプッシュリクエストを指定します。
```
"filterGroups": [
[
{
"type": "EVENT",
"pattern": "PULL_REQUEST_CREATED, PULL_REQUEST_UPDATED, PULL_REQUEST_CLOSED"
},
{
"type": "HEAD_REF",
"pattern": "^refs/heads/myBranch$"
},
{
"type": "BASE_REF",
"pattern": "^refs/heads/main$"
}
],
[
{
"type": "EVENT",
"pattern": "PUSH"
},
{
"type": "HEAD_REF",
"pattern": "^refs/heads/myBranch$"
}
]
]
```
`excludeMatchedPattern` パラメータを使用すると、ビルドをトリガーしないイベントを指定することができます。この例では、ビルドは、タグイベントを除くすべてのリクエストに対してトリガーされます。
```
"filterGroups": [
[
{
"type": "EVENT",
"pattern": "PUSH, PULL_REQUEST_CREATED, PULL_REQUEST_UPDATED, PULL_REQUEST_MERGED, PULL_REQUEST_CLOSED"
},
{
"type": "HEAD_REF",
"pattern": "^refs/tags/.*",
"excludeMatchedPattern": true
}
]
]
```
アカウント ID `actor-account-id` を持つ Bitbucket ユーザーによって変更が行われた場合にのみビルドをトリガーするフィルタを作成できます。
**注記**
Bitbucket アカウント ID の検索方法については、「https://api.bitbucket.org/2.0/users/*user-name*」を参照してください。ここで、*user-name* は、Bitbucket のユーザー名を表します。
```
"filterGroups": [
[
{
"type": "EVENT",
"pattern": "PUSH, PULL_REQUEST_CREATED, PULL_REQUEST_UPDATED, PULL_REQUEST_MERGED, PULL_REQUEST_CLOSED"
},
{
"type": "ACTOR_ACCOUNT_ID",
"pattern": "actor-account-id"
}
]
]
```
引数 `pattern` の正規表現に一致する名前のファイルが変更される場合にのみビルドをトリガーするフィルタを作成することができます。この例のフィルタグループでは、正規表現 `^buildspec.*` に一致する名前のファイルが変更された場合にのみビルドをトリガーするよう指定します。
```
"filterGroups": [
[
{
"type": "EVENT",
"pattern": "PUSH"
},
{
"type": "FILE_PATH",
"pattern": "^buildspec.*"
}
]
]
```
この例で、フィルターグループは、ファイルが `src` または `test` フォルダーで変更された場合にのみ、ビルドをトリガーするように指定しています。
```
"filterGroups": [
[
{
"type": "EVENT",
"pattern": "PUSH"
},
{
"type": "FILE_PATH",
"pattern": "^src/.+|^test/.+"
}
]
]
```
HEAD コミットメッセージがパターン引数の正規表現に一致する場合にのみビルドをトリガーするフィルタを作成できます。この例のフィルタグループでは、プッシュイベントの HEAD コミットメッセージが正規表現 `\[CodeBuild\]` に一致する場合にのみビルドをトリガーするよう指定します。
```
"filterGroups": [
[
{
"type": "EVENT",
"pattern": "PUSH"
},
{
"type": "COMMIT_MESSAGE",
"pattern": "\[CodeBuild\]"
}
]
]
```
# Bitbucket ウェブフックイベントのフィルタリング (CloudFormation)
CloudFormation テンプレートを使用してウェブフックイベントをフィルタリングするには、 AWS CodeBuild プロジェクトの `FilterGroups`プロパティを使用します。以下の YAML 形式の CloudFormation テンプレート部分によって、2 つのフィルタグループが作成されます。また、一方または両方が true と評価されると、ビルドがトリガーされます。
+ 最初のフィルタグループでは、アカウント ID `^refs/heads/main$` を持たない Bitbucket ユーザーが、正規表現 `12345` と一致する Git 参照名を持つブランチに対してプルリクエストを作成または更新することを指定します。
+ 2 番目のフィルタグループでは、正規表現 `^refs/heads/.*` と一致する Git 参照名を持つブランチに対するプッシュリクエストを作成することを指定します。
+ 3 番目のフィルタグループでは、正規表現 `\[CodeBuild\]` に一致する HEAD コミットメッセージを使用してプッシュリクエストを指定します。
```
CodeBuildProject:
Type: AWS::CodeBuild::Project
Properties:
Name: MyProject
ServiceRole: service-role
Artifacts:
Type: NO_ARTIFACTS
Environment:
Type: LINUX_CONTAINER
ComputeType: BUILD_GENERAL1_SMALL
Image: aws/codebuild/standard:5.0
Source:
Type: BITBUCKET
Location: source-location
Triggers:
Webhook: true
FilterGroups:
- - Type: EVENT
Pattern: PULL_REQUEST_CREATED,PULL_REQUEST_UPDATED
- Type: BASE_REF
Pattern: ^refs/heads/main$
ExcludeMatchedPattern: false
- Type: ACTOR_ACCOUNT_ID
Pattern: 12345
ExcludeMatchedPattern: true
- - Type: EVENT
Pattern: PUSH
- Type: HEAD_REF
Pattern: ^refs/heads/.*
- Type: FILE_PATH
Pattern: READ_ME
ExcludeMatchedPattern: true
- - Type: EVENT
Pattern: PUSH
- Type: COMMIT_MESSAGE
Pattern: \[CodeBuild\]
- Type: FILE_PATH
Pattern: ^src/.+|^test/.+
```
# GitHub グローバルおよび組織のウェブフック
CodeBuild GitHub グローバルまたは組織のウェブフックを使用して、GitHub 組織またはエンタープライズ内の任意のリポジトリからのウェブフックイベントでビルドを開始できます。グローバルおよび組織のウェブフックは、既存の GitHub ウェブフックイベントタイプのいずれでも動作し、CodeBuild ウェブフックの作成時にスコープ設定を追加することで設定できます。グローバルおよび組織のウェブフックを使用して [CodeBuild 内でセルフホスト型 GitHub Action Runner を設定](action-runner.md)し、単一のプロジェクト内の複数のリポジトリから `WORKFLOW_JOB_QUEUED` イベントを受信することもできます。
**Topics**
+ [
# グローバルまたは組織の GitHub ウェブフックを設定
](github-global-organization-webhook-setup.md)
+ [
# GitHub グローバルまたは組織のウェブフックイベントをフィルタリング (コンソール)
](github-global-organization-webhook-events-console.md)
+ [
# GitHub 組織のウェブフックイベントをフィルタリング (CloudFormation)
](github-organization-webhook-events-cfn.md)
# グローバルまたは組織の GitHub ウェブフックを設定
グローバルまたは組織の GitHub ウェブフックを設定するための大まかなステップは次のとおりです。グローバルおよび組織の GitHub ウェブフックの詳細については、「[GitHub グローバルおよび組織のウェブフック](github-global-organization-webhook.md)」を参照してください。
1. プロジェクトのソースの場所を `CODEBUILD_DEFAULT_WEBHOOK_SOURCE_LOCATION` に設定します。
1. ウェブフックのスコープ設定で、組織か[グローバルウェブフック](https://docs.github.com/en/enterprise-cloud@latest/admin/monitoring-activity-in-your-enterprise/exploring-user-activity-in-your-enterprise/managing-global-webhooks)かに応じて、スコープを `GITHUB_ORGANIZATION` または `GITHUB_GLOBAL` に設定します。詳細については、「[Types of webhooks](https://docs.github.com/en/webhooks/types-of-webhooks)」を参照してください。
1. ウェブフックのスコープ設定の一部として名前を指定します。組織ウェブフックの場合、これは組織名であり、グローバルウェブフックの場合、これはエンタープライズ名です。
**注記**
プロジェクトのソースタイプが `GITHUB_ENTERPRISE` の場合、ウェブフックスコープ設定の一部としてドメインも指定する必要があります。
1. (オプション) 組織またはエンタープライズ内の特定のリポジトリのウェブフックイベントのみを受信する場合は、ウェブフックの作成時に `REPOSITORY_NAME` をフィルタとして指定できます。
1. 組織ウェブフックを作成する場合は、CodeBuild に GitHub 内で組織レベルのウェブフックを作成するアクセス許可があることを確認してください。組織のウェブフックアクセス許可を持つ GitHub 個人用アクセストークンを作成するか、CodeBuild OAuth を使用できます。詳細については、「[GitHub および GitHub Enterprise Server アクセストークン](access-tokens-github.md)」を参照してください。
組織のウェブフックは、既存の GitHub ウェブフックイベントタイプのいずれでも動作することに注意してください。
1. グローバルウェブフックを作成する場合は、ウェブフックを手動で作成する必要があります。GitHub 内でウェブフックを手動で作成する方法の詳細については、「[GitHub 手動ウェブフック](github-manual-webhook.md)」を参照してください。
グローバルウェブフックは `WORKFLOW_JOB_QUEUED` イベントタイプのみをサポートすることに注意してください。詳細については、「[チュートリアル: CodeBuild がホストする GitHub Actions ランナーを設定](action-runner.md)」を参照してください。
# GitHub グローバルまたは組織のウェブフックイベントをフィルタリング (コンソール)
コンソールから GitHub プロジェクトを作成するときは、次のオプションを選択して、プロジェクト内に GitHub グローバルまたは組織のウェブフックを作成します。グローバルおよび組織の GitHub ウェブフックの詳細については、「[GitHub グローバルおよび組織のウェブフック](github-global-organization-webhook.md)」を参照してください。
1. [https://console.aws.amazon.com/codesuite/codebuild/home](https://console.aws.amazon.com/codesuite/codebuild/home) で AWS CodeBuild コンソールを開きます。
1. ビルドプロジェクトを作成します。詳細については、「[ビルドプロジェクトの作成 (コンソール)](create-project.md#create-project-console)」および「[ビルドの実行 (コンソール)](run-build-console.md)」を参照してください。
+ [**Source (ソース)**] で、次のようにします。
+ **[ソースプロバイダ]** には、**[GitHub]**、または **[GitHub Enterprise]** を選択します。
+ **[リポジトリ]** で、**[GitHub スコープ付きウェブフック]** を選択します。
GitHub リポジトリは自動的に `CODEBUILD_DEFAULT_WEBHOOK_SOURCE_LOCATION` に設定されます。これは、グローバルおよび組織のウェブフックに必要なソースの場所です。
**注記**
組織ウェブフックを使用している場合は、CodeBuild に GitHub 内で組織レベルのウェブフックを作成するアクセス許可があることを確認してください。[既存の OAuth 接続](oauth-app-github.md)を使用している場合は、CodeBuild にこのアクセス許可を付与するために、接続を再生成する必要がある場合があります。または、[CodeBuild の手動ウェブフック機能](github-manual-webhook.md)を使用して、ウェブフックを手動で作成することもできます。既存の GitHub OAuth トークンがあり、追加の組織アクセス許可を追加する場合は、[OAuth トークンのアクセス許可を取り消し](https://docs.github.com/en/apps/oauth-apps/using-oauth-apps/reviewing-your-authorized-oauth-apps)、CodeBuild コンソールからトークンを再接続できます。
![\[GitHub スコープ付きウェブフックの設定。\]](http://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/images/github-organization-webhook-source.png)
+ **[プライマリソースのウェブフックイベント]** の場合:
+ **[スコープタイプ]** では、組織ウェブフックを作成する場合は **[組織レベル]**、グローバルウェブフックを作成する場合は **[エンタープライズレベル]** を選択します。
+ **[名前]** には、ウェブフックがグローバルウェブフックか組織ウェブフックかに応じて、エンタープライズまたは組織名を入力します。
プロジェクトのソースタイプが `GITHUB_ENTERPRISE` の場合、ウェブフック組織設定の一部としてドメインも指定する必要があります。例えば、組織の URL が **https://domain.com/orgs/org-name** の場合、ドメインは **https://domain.com** です。
**注記**
この名前をウェブフックの作成後に変更することはできません。名前を変更するには、ウェブフックを削除して再作成します。ウェブフックを完全に削除する場合は、プロジェクトソースの場所を GitHub リポジトリに更新することもできます。
![\[グローバルまたは組織のウェブフックの設定。\]](http://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/images/github-organization-webhook-primary-events.png)
+ (オプション) **[ウェブフックイベントフィルタグループ]** では、[新しいビルドをトリガーするイベント](github-webhook.md)を指定できます。また、`REPOSITORY_NAME` をフィルタとして指定して、特定のリポジトリからのウェブフックイベントでのみ、ビルドをトリガーすることもできます。
![\[特定のリポジトリからのウェブフックイベントでのみビルドをトリガーするフィルタです。\]](http://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/images/github-organization-webhook-filter-groups.png)
イベントタイプを `WORKFLOW_JOB_QUEUED` に設定して、セルフホスト型 GitHub Actions ランナーを設定することもできます。詳細については、「[チュートリアル: CodeBuild がホストする GitHub Actions ランナーを設定](action-runner.md)」を参照してください。
1. デフォルト値のまま続行し、**[ビルドプロジェクトを作成する]** を選択します。
# GitHub 組織のウェブフックイベントをフィルタリング (CloudFormation)
CloudFormation テンプレートを使用して組織のウェブフックイベントを AWS CodeBuild フィルタリングするには、プロジェクトの `ScopeConfiguration`プロパティを使用します。グローバルおよび組織の GitHub ウェブフックの詳細については、「[GitHub グローバルおよび組織のウェブフック](github-global-organization-webhook.md)」を参照してください。
**注記**
グローバルウェブフックと GitHub Enterprise ウェブフックは ではサポートされていません CloudFormation。
CloudFormation テンプレートの次の YAML 形式の部分は、4 つのフィルターグループを作成します。1 つまたはすべてが true と評価されると、これらが一緒になってビルドをトリガーします。
+ 最初のフィルタグループでは、アカウント ID `^refs/heads/main$` を持たない GitHub ユーザーが、正規表現 `12345` と一致する Git 参照名を持つブランチに対してプルリクエストを作成または更新することを指定します。
+ 2 番目のフィルターグループでは、正規表現 `READ_ME` に一致する Git 参照名を持つブランチで正規表現 `^refs/heads/.*` に一致する名前のファイルに対してプッシュリクエストが作成されることを指定します。
+ 3 番目のフィルタグループでは、正規表現 `\[CodeBuild\]` に一致する HEAD コミットメッセージを使用してプッシュリクエストを指定します。
+ 4 番目のフィルタグループは、正規表現 `\[CI-CodeBuild\]` に一致するワークフロー名を持つ GitHub Actions ワークフロージョブリクエストを指定します。
```
CodeBuildProject:
Type: AWS::CodeBuild::Project
Properties:
Name: MyProject
ServiceRole: service-role
Artifacts:
Type: NO_ARTIFACTS
Environment:
Type: LINUX_CONTAINER
ComputeType: BUILD_GENERAL1_SMALL
Image: aws/codebuild/standard:5.0
Source:
Type: GITHUB
Location: source-location
Triggers:
Webhook: true
ScopeConfiguration:
Name: organization-name
Scope: GITHUB_ORGANIZATION
FilterGroups:
- - Type: EVENT
Pattern: PULL_REQUEST_CREATED,PULL_REQUEST_UPDATED
- Type: BASE_REF
Pattern: ^refs/heads/main$
ExcludeMatchedPattern: false
- Type: ACTOR_ACCOUNT_ID
Pattern: 12345
ExcludeMatchedPattern: true
- - Type: EVENT
Pattern: PUSH
- Type: HEAD_REF
Pattern: ^refs/heads/.*
- Type: FILE_PATH
Pattern: READ_ME
ExcludeMatchedPattern: true
- - Type: EVENT
Pattern: PUSH
- Type: COMMIT_MESSAGE
Pattern: \[CodeBuild\]
- Type: FILE_PATH
Pattern: ^src/.+|^test/.+
- - Type: EVENT
Pattern: WORKFLOW_JOB_QUEUED
- Type: WORKFLOW_NAME
Pattern: \[CI-CodeBuild\]
```
# GitHub 手動ウェブフック
手動 GitHub ウェブフックを設定して、CodeBuild が GitHub 内で自動的にウェブフックを作成するのを防ぐことができます。CodeBuild は、ウェブフックを作成するための呼び出しの一部としてペイロード URL を返します。これを使用して、GitHub 内でウェブフックを手動で作成できます。GitHub アカウントでのウェブフックの作成を許可するリストに CodeBuild が登録されていない場合でも、ビルドプロジェクト用にウェブフックを手動で作成できます。
GitHub 手動ウェブフックを作成するには、次の手順に従います。
**GitHub 手動ウェブフックを作成するには**
1. [https://console.aws.amazon.com/codesuite/codebuild/home](https://console.aws.amazon.com/codesuite/codebuild/home) で AWS CodeBuild コンソールを開きます。
1. ビルドプロジェクトを作成します。詳細については、「[ビルドプロジェクトの作成 (コンソール)](create-project.md#create-project-console)」および「[ビルドの実行 (コンソール)](run-build-console.md)」を参照してください。
+ [**Source (ソース)**] で、次のようにします。
+ [**ソースプロバイダー**] で [**GitHub**] を選択します。
+ **[リポジトリ]** では、**[GitHub アカウントのリポジトリ]** を選択します。
+ [**リポジトリの URL**] に、「**https://github.com/*user-name*/*repository-name***」と入力します。
+ **[プライマリソースのウェブフックイベント]** の場合:
+ **[ウェブフック - オプション]** で、**[コードの変更がこのレポジトリにプッシュされるたびに再ビルド]** を選択します。
+ **[追加設定]** を選択し、**[手動作成 - オプション]** で、**[GitHub コンソールでこのリポジトリのウェブフックを手動で作成]** を選択します。
1. デフォルト値のまま続行し、**[ビルドプロジェクトを作成する]** を選択します。**[ペイロード URL]** と **[シークレット]** 値は後で使用するため、メモしておきます。
![\[手動ウェブフックのペイロード URL とシークレット設定。\]](http://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/images/github-manual-webhook-values.png)
1. `https://github.com/user-name/repository-name/settings/hooks` で GitHub コンソールを開き、**[ウェブフックを追加]** を選択します。
+ **[ペイロード URL]** には、先ほどメモしたペイロード URL 値を入力します。
+ **[コンテンツタイプ]** には、**[application/json]** を選択します。
+ **[シークレット]** には、先ほどメモしたシークレット値を入力します。
+ CodeBuild にウェブフックペイロードを送信する個々のイベントを設定します。**[このウェブフックをトリガーするイベント]** として、**[個々のイベントを選択]** を選択し、**[プッシュ]**、**[プルリクエスト]**、および **[リリース]** のイベントから選択します。`WORKFLOW_JOB_QUEUED` イベントのビルドを開始する場合は、**[ワークフロージョブ]** を選択します。GitHub Actions ランナーの詳細については、「[チュートリアル: CodeBuild がホストする GitHub Actions ランナーを設定](action-runner.md)」を参照してください。CodeBuild でサポートされているイベントタイプの詳細については、「[GitHub ウェブフックイベント](github-webhook.md)」を参照してください。
1. **[ウェブフックを追加]** を選択します。
# GitHub ウェブフックイベント
Webhook フィルタグループを使用して、ビルドをトリガーする GitHub ウェブフックイベントを指定できます。たとえば、特定のブランチへの変更に対してのみビルドをトリガーするように指定できます。
ビルドをトリガーするウェブフックイベントを指定するには、ウェブフックフィルタグループを 1 つ以上作成できます。任意のフィルターグループが true と評価されると、ビルドがトリガーされます。これは、グループ内のすべてのフィルターが true と評価されたときに発生します。フィルタグループを作成する際、以下を指定します。
**イベント**
GitHub では、次のイベントのうち、1 つ以上を選択できます: `PUSH`、`PULL_REQUEST_CREATED`、`PULL_REQUEST_UPDATED`、`PULL_REQUEST_REOPENED`、`PULL_REQUEST_MERGED`、`PULL_REQUEST_CLOSED`、`RELEASED`、`PRERELEASED`、`WORKFLOW_JOB_QUEUED`。ウェブフックのイベントタイプは、ウェブフックペイロードの `X-GitHub-Event` ヘッダーに含まれています。`X-GitHub-Event` ヘッダーで、`pull_request` または `push` が表示される場合があります。プルリクエストイベントの場合、このタイプはウェブフックイベントペイロードの `action` フィールドに含まれています。以下の表に示すのは、`X-GitHub-Event` ヘッダー値とウェブフックのプルリクエストペイロードの `action` フィールドが、利用可能なイベントタイプにマッピングされる方法を示しています。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/github-webhook.html)
`PULL_REQUEST_REOPENED` イベントタイプは GitHub および GitHub Enterprise Server でのみ使用できます。`RELEASED` および `PRERELEASED` イベントタイプは、GitHub のみで使用できます。`WORKFLOW_JOB_QUEUED` の詳細については、「[チュートリアル: CodeBuild がホストする GitHub Actions ランナーを設定](action-runner.md)」をご参照ください。
**1 つ以上のオプションフィルタ**
フィルタを指定するには、正規表現を使用します。ビルドをトリガーするイベントでは、関連付けられているグループ内のすべてのフィルターが true と評価される必要があります。
`ACTOR_ACCOUNT_ID` (コンソール内の `ACTOR_ID`)
GitHub、GitHub Enterprise サーバーのアカウント ID が正規表現 パターンと一致すると、Webhook イベントによってビルドがトリガーされます。この値は、ウェブフックペイロードの `sender` オブジェクトの `id` プロパティで見つかります。
`HEAD_REF`
ヘッドリファレンスが正規表現パターンと一致すると、ウェブフックイベントによりビルドがトリガーされます (例: `refs/heads/branch-name` または `refs/tags/tag-name`)。プッシュイベントの場合、参照名はウェブフックペイロードの `ref` プロパティで見つかります。プルリクエストイベントの場合、ブランチ名はウェブフックペイロードの `head` オブジェクトの `ref` プロパティで見つかります。
`BASE_REF`
基本参照が正規表現パターンと一致するとウェブフックイベントによってビルドがトリガーされます。(例 `refs/heads/branch-name`) `BASE_REF` フィルタは、プルリクエストイベントでのみ使用できます。ブランチ名は、ウェブフックペイロードで `base` オブジェクトの `ref` プロパティで見つかります。
`FILE_PATH`
変更されたファイルのパスが正規表現パターンと一致すると、ビルドがウェブフックイベントでトリガーされます。`FILE_PATH` フィルタは、GitHub のプッシュおよびプルリクエストイベントと GitHub Enterprise Server のプッシュイベントで使用できます。GitHub Enterprise Server のプルリクエストイベントでは使用できません。
`COMMIT_MESSAGE`
HEAD コミットメッセージが正規表現パターンに一致する場合に、Webhook はビルドをトリガーします。`COMMIT_MESSAGE` フィルタは、GitHub のプッシュおよびプルリクエストイベントと GitHub Enterprise Server のプッシュイベントで使用できます。GitHub Enterprise Server のプルリクエストイベントでは使用できません。
`TAG_NAME`
リリースのタグ名が正規表現パターンに一致すると、ウェブフックはビルドをトリガーします。`TAG_NAME` フィルタは、GitHub リリースおよびプレリリースされたリクエストイベントで使用できます。
`RELEASE_NAME`
リリース名が正規表現パターンに一致すると、ウェブフックはビルドをトリガーします。`RELEASE_NAME` フィルタは、GitHub リリースおよびプレリリースされたリクエストイベントで使用できます。
`REPOSITORY_NAME`
リポジトリ名が正規表現パターンに一致すると、ウェブフックはビルドをトリガーします。`REPOSITORY_NAME` フィルタは、GitHub グローバルまたは組織のウェブフックでのみ使用できます。
`ORGANIZATION_NAME`
組織名が正規表現パターンに一致する場合に、ウェブフックはビルドをトリガーします。`ORGANIZATION_NAME` フィルタは、GitHub グローバルウェブフックでのみ使用できます。
`WORKFLOW_NAME`
ワークフロー名が正規表現パターンに一致する場合に、ウェブフックはビルドをトリガーします。`WORKFLOW_NAME` フィルタは、GitHub Actions ワークフロージョブのキューに入れられたリクエストイベントで使用できます。
**注記**
ウェブフックペイロードは、GitHub リポジトリのウェブフック設定で見つかります。
**Topics**
+ [
# GitHub ウェブフックイベントのフィルタリング (コンソール)
](github-webhook-events-console.md)
+ [
# GitHub ウェブフックイベントのフィルタリング (SDK)
](github-webhook-events-sdk.md)
+ [
# GitHub ウェブフックイベントのフィルタリング (CloudFormation)
](github-webhook-events-cfn.md)
# GitHub ウェブフックイベントのフィルタリング (コンソール)
AWS マネジメントコンソールを使用して GitHub ウェブフックイベントをフィルタリングするには、次の手順を使用します。GitHub ウェブフックイベントの詳細については、「[GitHub ウェブフックイベント](github-webhook.md)」を参照してください。
[**プライマリソース Webhook イベント**] で、以下を選択します。このセクションは、ソースリポジトリで **[GitHub アカウントのリポジトリ]** を選択した場合のみに表示されます｡
1. プロジェクトの作成時に [**コードの変更がこのレポジトリにプッシュされるたびに再構築する**] を選択します。
1. [**イベントタイプ**] から、1 つ以上のイベントを選択します。
1. イベントでビルドをトリガーされた時間をフィルタリングするには、[**これらの条件でビルドを開始する**] で、1 つ以上のオプションフィルタを追加します。
1. イベントがトリガーされていない時間をフィルタリングするには、[**これらの条件でビルドを開始しない**] で、1 つ以上のオプションフィルタを追加します。
1. 別のフィルタグループを追加する必要がある場合、[**フィルタグループの追加**] を選択します。
詳細については、「*AWS CodeBuild API リファレンス*」の「[ビルドプロジェクトの作成 (コンソール)](create-project.md#create-project-console)」および「[WebhookFilter](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_WebhookFilter.html)」を参照してください。
この例では、ウェブフックフィルタグループは、プルリクエストに対してのみビルドをトリガーします。
![\[プルリクエストのみのビルドをトリガーするウェブフックフィルタグループ。\]](http://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/images/pull-request-webhook-filter.png)
2 つのウェブフックフィルタグループの例を使用した場合、ビルドは一方または両方が true と評価されるとトリガーされます。
+ 最初のフィルタグループでは、正規表現 `^refs/heads/main$` と一致する Git 参照名および `^refs/heads/branch1$` と一致するヘッド参照を持つブランチに対してプルリクエストを作成、更新、または再開することを指定します。
+ 2 番目のフィルタグループでは、正規表現 `^refs/heads/branch1$` に一致する Git 参照を含むブランチでプッシュリクエストを指定します。
![\[2 つのフィルタグループの例です。\]](http://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/images/pull-request-webhook-filter-head-base-regexes.png)
この例では、ウェブフックフィルタグループは、タグイベントを除くすべてのリクエストに対してビルドをトリガーします。
![\[タグイベントを除くすべてのリクエストに対してビルドをトリガーする、ウェブフックフィルタグループです。\]](http://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/images/pull-request-webhook-filter-exclude.png)
この例では、ウェブフックフィルタグループは、正規表現 `^buildspec.*` に一致する名前のファイルが変更された場合にのみビルドをトリガーします。
![\[指定された正規表現に一致する名前のファイルに対してのみビルドをトリガーする、ウェブフックフィルタグループです。\]](http://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/images/pull-request-webhook-filter-file-name-regex.png)
この例で、Webhook フィルターグループは、ファイルが `src` または `test` フォルダーで変更された場合にのみ、ビルドをトリガーします。
![\[指定されたフォルダ内でファイルが変更された場合にのみビルドをトリガーする、ウェブフックフィルタグループです。\]](http://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/images/pull-request-webhook-filter-file-name-combined-regex.png)
この例では、指定した GitHub ユーザーや GitHub Enterprise Server ユーザーが、正規表現 `actor-account-id` と一致するアカウント ID を使用して変更を行った場合にのみ、Webhook フィルタグループがビルドをトリガーします。
**注記**
GitHub アカウント ID の検索方法については、「https://api.github.com/users/*user-name*」を参照してください。ここで、*user-name* は、GitHub のユーザー名を表します。
![\[ウェブフックフィルタグループは、指定された GitHub ユーザーが正規表現と一致するアカウント ID を使用して変更を行った場合にのみ、ビルドをトリガーします。\]](http://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/images/pull-request-webhook-filter-actor.png)
この例では、HEAD コミットメッセージが正規表現 `\[CodeBuild\]` に一致する場合に、Webhook フィルタグループがプッシュイベントのビルドをトリガーします。
![\[HEAD コミットメッセージが正規表現に一致する場合に、プッシュイベントのビルドをトリガーするウェブフックフィルタグループです。\]](http://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/images/pull-request-webhook-filter-commit-message.png)
この例では、ウェブフックフィルタグループは GitHub Actions ワークフロージョブイベントのみのビルドをトリガーします。
**注記**
CodeBuild は、ウェブフックに **[WORKFLOW\$1JOB\$1QUEUED]** イベントフィルタを含むフィルタグループがある場合にのみ、GitHub Actions ワークフロージョブを処理します。
![\[GitHub Actions ワークフロージョブイベントのみのビルドをトリガーするウェブフックフィルタグループです。\]](http://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/images/github-actions-workflow-job-queued-no-highlight.png)
この例では、ウェブフックフィルタグループが、正規表現 `CI-CodeBuild` に一致するワークフロー名のビルドをトリガーします。
![\[正規表現に一致するワークフロー名のビルドをトリガーするウェブフックフィルタグループです。\]](http://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/images/github-actions-workflow-job-specific.png)
# GitHub ウェブフックイベントのフィルタリング (SDK)
AWS CodeBuild SDK を使用してウェブフックイベントをフィルタリングするには、 `CreateWebhook`または `UpdateWebhook` API メソッドのリクエスト構文で `filterGroups`フィールドを使用します。詳細については、*CodeBuild API リファレンス*の「[WebhookFilter](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_WebhookFilter.html)」を参照してください。
GitHub ウェブフックイベントの詳細については、「[GitHub ウェブフックイベント](github-webhook.md)」を参照してください。
プルリクエストに対してのみビルドをトリガーするウェブフックフィルタを作成するには、以下をリクエスト構文に挿入します。
```
"filterGroups": [
[
{
"type": "EVENT",
"pattern": "PULL_REQUEST_CREATED, PULL_REQUEST_UPDATED, PULL_REQUEST_REOPENED, PULL_REQUEST_MERGED, PULL_REQUEST_CLOSED"
}
]
]
```
指定されたブランチに対してのみビルドをトリガーするウェブフックフィルタを作成するには、`pattern` パラメータを使用して、ブランチ名をフィルタリングするよう正規表現を指定します。2 つのフィルタグループの例を使用した場合、ビルドは一方または両方が true と評価されるとトリガーされます。
+ 最初のフィルタグループでは、正規表現 `^refs/heads/main$` と一致する Git 参照名および `^refs/heads/myBranch$` と一致するヘッド参照を持つブランチに対してプルリクエストを作成、更新、または再開することを指定します。
+ 2 番目のフィルタグループでは、正規表現 `^refs/heads/myBranch$` に一致する Git 参照を含むブランチでプッシュリクエストを指定します。
```
"filterGroups": [
[
{
"type": "EVENT",
"pattern": "PULL_REQUEST_CREATED, PULL_REQUEST_UPDATED, PULL_REQUEST_REOPENED"
},
{
"type": "HEAD_REF",
"pattern": "^refs/heads/myBranch$"
},
{
"type": "BASE_REF",
"pattern": "^refs/heads/main$"
}
],
[
{
"type": "EVENT",
"pattern": "PUSH"
},
{
"type": "HEAD_REF",
"pattern": "^refs/heads/myBranch$"
}
]
]
```
`excludeMatchedPattern` パラメータを使用すると、ビルドをトリガーしないイベントを指定することができます。たとえば、この例で、ビルドは、タグイベントを除くすべてのリクエストに対してトリガーされます。
```
"filterGroups": [
[
{
"type": "EVENT",
"pattern": "PUSH, PULL_REQUEST_CREATED, PULL_REQUEST_UPDATED, PULL_REQUEST_REOPENED, PULL_REQUEST_MERGED, PULL_REQUEST_CLOSED"
},
{
"type": "HEAD_REF",
"pattern": "^refs/tags/.*",
"excludeMatchedPattern": true
}
]
]
```
引数 `pattern` の正規表現に一致する名前のファイルが変更される場合にのみビルドをトリガーするフィルタを作成することができます。この例のフィルタグループでは、正規表現 `^buildspec.*` に一致する名前のファイルが変更された場合にのみビルドをトリガーするよう指定します。
```
"filterGroups": [
[
{
"type": "EVENT",
"pattern": "PUSH"
},
{
"type": "FILE_PATH",
"pattern": "^buildspec.*"
}
]
]
```
この例で、フィルターグループは、ファイルが `src` または `test` フォルダーで変更された場合にのみ、ビルドをトリガーするように指定しています。
```
"filterGroups": [
[
{
"type": "EVENT",
"pattern": "PUSH"
},
{
"type": "FILE_PATH",
"pattern": "^src/.+|^test/.+"
}
]
]
```
指定した GitHub ユーザーまたは GitHub Enterprise Server ユーザーがアカウント ID `actor-account-id` を使用して変更を行った場合にのみ、ビルドをトリガーするフィルタを作成できます。
**注記**
GitHub アカウント ID の検索方法については、「https://api.github.com/users/*user-name*」を参照してください。ここで、*user-name* は、GitHub のユーザー名を表します。
```
"filterGroups": [
[
{
"type": "EVENT",
"pattern": "PUSH, PULL_REQUEST_CREATED, PULL_REQUEST_UPDATED, PULL_REQUEST_REOPENED, PULL_REQUEST_MERGED, PULL_REQUEST_CLOSED"
},
{
"type": "ACTOR_ACCOUNT_ID",
"pattern": "actor-account-id"
}
]
]
```
HEAD コミットメッセージがパターン引数の正規表現に一致する場合にのみビルドをトリガーするフィルタを作成できます。この例のフィルタグループでは、プッシュイベントの HEAD コミットメッセージが正規表現 `\[CodeBuild\]` に一致する場合にのみビルドをトリガーするよう指定します。
```
"filterGroups": [
[
{
"type": "EVENT",
"pattern": "PUSH"
},
{
"type": "COMMIT_MESSAGE",
"pattern": "\[CodeBuild\]"
}
]
]
```
GitHub Actions ワークフロージョブのビルドのみをトリガーするウェブフックフィルタを作成するには、リクエスト構文に以下を挿入します。
```
"filterGroups": [
[
{
"type": "EVENT",
"pattern": "WORKFLOW_JOB_QUEUED"
}
]
]
```
# GitHub ウェブフックイベントのフィルタリング (CloudFormation)
CloudFormation テンプレートを使用してウェブフックイベントをフィルタリングするには、 AWS CodeBuild プロジェクトの `FilterGroups`プロパティを使用します。
GitHub ウェブフックイベントの詳細については、「[GitHub ウェブフックイベント](github-webhook.md)」を参照してください。
以下の YAML 形式の CloudFormation テンプレート部分によって、2 つのフィルタグループが作成されます。また、一方または両方が true と評価されると、ビルドがトリガーされます。
+ 最初のフィルタグループでは、アカウント ID `^refs/heads/main$` を持たない GitHub ユーザーが、正規表現 `12345` と一致する Git 参照名を持つブランチに対してプルリクエストを作成または更新することを指定します。
+ 2 番目のフィルターグループでは、正規表現 `READ_ME` に一致する Git 参照名を持つブランチで正規表現 `^refs/heads/.*` に一致する名前のファイルに対してプッシュリクエストが作成されることを指定します。
+ 3 番目のフィルタグループでは、正規表現 `\[CodeBuild\]` に一致する HEAD コミットメッセージを使用してプッシュリクエストを指定します。
+ 4 番目のフィルタグループは、正規表現 `\[CI-CodeBuild\]` に一致するワークフロー名を持つ GitHub Actions ワークフロージョブリクエストを指定します。
```
CodeBuildProject:
Type: AWS::CodeBuild::Project
Properties:
Name: MyProject
ServiceRole: service-role
Artifacts:
Type: NO_ARTIFACTS
Environment:
Type: LINUX_CONTAINER
ComputeType: BUILD_GENERAL1_SMALL
Image: aws/codebuild/standard:5.0
Source:
Type: GITHUB
Location: source-location
Triggers:
Webhook: true
FilterGroups:
- - Type: EVENT
Pattern: PULL_REQUEST_CREATED,PULL_REQUEST_UPDATED
- Type: BASE_REF
Pattern: ^refs/heads/main$
ExcludeMatchedPattern: false
- Type: ACTOR_ACCOUNT_ID
Pattern: 12345
ExcludeMatchedPattern: true
- - Type: EVENT
Pattern: PUSH
- Type: HEAD_REF
Pattern: ^refs/heads/.*
- Type: FILE_PATH
Pattern: READ_ME
ExcludeMatchedPattern: true
- - Type: EVENT
Pattern: PUSH
- Type: COMMIT_MESSAGE
Pattern: \[CodeBuild\]
- Type: FILE_PATH
Pattern: ^src/.+|^test/.+
- - Type: EVENT
Pattern: WORKFLOW_JOB_QUEUED
- Type: WORKFLOW_NAME
Pattern: \[CI-CodeBuild\]
```
# GitLab グループウェブフック
CodeBuild GitLab グループウェブフックを使用して、GitLab グループ内の任意のリポジトリからウェブフックイベントでビルドを開始できます。グループウェブフックは、既存の GitLab ウェブフックイベントタイプのいずれでも動作し、CodeBuild ウェブフックの作成時にスコープ設定を追加することで設定できます。グループウェブフックを使用して [CodeBuild 内でセルフホスト型 GitLab ランナーを設定](gitlab-runner.md)し、単一のプロジェクト内の複数のリポジトリから `WORKFLOW_JOB_QUEUED` イベントを受信することもできます。
**Topics**
+ [
# グループ GitLab ウェブフックを設定
](gitlab-group-webhook-setup.md)
+ [
# GitLab グループウェブフックイベントのフィルタリング (コンソール)
](gitlab-group-webhook-events-console.md)
+ [
# GitLab グループウェブフックイベントのフィルタリング (CloudFormation)
](gitlab-group-webhook-events-cfn.md)
# グループ GitLab ウェブフックを設定
グループ GitLab ウェブフックを設定する大まかなステップは次のとおりです。グループ GitLab ウェブフックの詳細については、「[GitLab グループウェブフック](gitlab-group-webhook.md)」を参照してください。
1. プロジェクトのソースの場所を `CODEBUILD_DEFAULT_WEBHOOK_SOURCE_LOCATION` に設定します。
1. ウェブフックのスコープ設定で、スコープを `GITLAB_GROUP` に設定します。
1. ウェブフックのスコープ設定の一部として名前を指定します。グループウェブフックの場合、これはグループ名です。
**注記**
プロジェクトのソースタイプが `GITLAB_SELF_MANAGED` の場合、ウェブフックスコープ設定の一部としてドメインも指定する必要があります。
1. (オプション) 組織またはエンタープライズ内の特定のリポジトリのウェブフックイベントのみを受信する場合は、ウェブフックの作成時に `REPOSITORY_NAME` をフィルタとして指定できます。
1. グループウェブフックを作成するときは、CodeBuild に GitLab 内でグループレベルのウェブフックを作成するアクセス許可があることを確認してください。CodeConnections から CodeBuild OAuth を使用して確認できます。詳細については、「[CodeBuild での GitLab アクセス](access-tokens-gitlab-overview.md)」を参照してください。
グループウェブフックは、既存の GitLab ウェブフックイベントタイプのいずれでも動作することに注意してください。
# GitLab グループウェブフックイベントのフィルタリング (コンソール)
コンソールから GitLab プロジェクトを作成するときは、次のオプションを選択して、プロジェクト内に GitLab グループウェブフックを作成します。グループ GitLab ウェブフックの詳細については、「[GitLab グループウェブフック](gitlab-group-webhook.md)」を参照してください。
1. [https://console.aws.amazon.com/codesuite/codebuild/home](https://console.aws.amazon.com/codesuite/codebuild/home) で AWS CodeBuild コンソールを開きます。
1. ビルドプロジェクトを作成します。詳細については、「[ビルドプロジェクトの作成 (コンソール)](create-project.md#create-project-console)」および「[ビルドの実行 (コンソール)](run-build-console.md)」を参照してください。
+ [**Source (ソース)**] で、次のようにします。
+ **[ソースプロバイダ]** では、**[GitLab]** または **[GitLab セルフマネージド]** を選択します。
+ **[リポジトリ]** で、**[GitLab スコープ付きウェブフック]** を選択します。
GitLab リポジトリは自動的に `CODEBUILD_DEFAULT_WEBHOOK_SOURCE_LOCATION` に設定されます。これは、グループウェブフックに必要なソースの場所です。
**注記**
グループウェブフックを使用するときは、CodeBuild に GitLab 内でグループレベルのウェブフックを作成するアクセス許可があることを確認してください。[既存の OAuth 接続](access-tokens-gitlab-overview.md#connections-gitlab)を使用している場合は、CodeBuild にこのアクセス許可を付与するために、接続を再生成する必要がある場合があります。
![\[GitLab スコープ付きウェブフックの設定。\]](http://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/images/gitlab-group-source.png)
+ **[プライマリソースのウェブフックイベント]** の場合:
+ **[グループ名]** に、グループ名を入力します。
プロジェクトのソースタイプが `GITLAB_SELF_MANAGED` の場合、ウェブフックグループ設定の一部としてドメインも指定する必要があります。例えば、グループの URL が **https://domain.com/group/group-name** の場合、ドメインは **https://domain.com** です。
**注記**
この名前をウェブフックの作成後に変更することはできません。名前を変更するには、ウェブフックを削除して再作成します。ウェブフックを完全に削除する場合は、プロジェクトソースの場所を GitLab リポジトリに更新することもできます。
![\[グループウェブフックの設定。\]](http://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/images/gitlab-group-webhook-primary-events.png)
+ (オプション) **[ウェブフックイベントフィルタグループ]** では、[新しいビルドをトリガーするイベント](gitlab-webhook.md)を指定できます。また、`REPOSITORY_NAME` をフィルタとして指定して、特定のリポジトリからのウェブフックイベントでのみ、ビルドをトリガーすることもできます。
![\[特定のリポジトリからのウェブフックイベントでのみビルドをトリガーするフィルタです。\]](http://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/images/github-organization-webhook-filter-groups.png)
イベントタイプを `WORKFLOW_JOB_QUEUED` に設定して、セルフホスト型 GitLab ランナーを設定することもできます。詳細については、「[のセルフマネージド型 GitLab ランナー AWS CodeBuild](gitlab-runner.md)」を参照してください。
1. デフォルト値のまま続行し、**[ビルドプロジェクトを作成する]** を選択します。
# GitLab グループウェブフックイベントのフィルタリング (CloudFormation)
CloudFormation テンプレートを使用してグループウェブフックイベントを AWS CodeBuild フィルタリングするには、プロジェクトの `ScopeConfiguration`プロパティを使用します。グループ GitLab ウェブフックの詳細については、「[GitLab グループウェブフック](gitlab-group-webhook.md)」を参照してください。
CloudFormation テンプレートの次の YAML 形式の部分は、4 つのフィルターグループを作成します。1 つまたはすべてが true と評価されると、これらが一緒になってビルドをトリガーします。
+ 最初のフィルタグループでは、アカウント ID `12345` を持たない GitLab ユーザーが、正規表現 `^refs/heads/main$` と一致する Git 参照名を持つブランチに対してプルリクエストを作成または更新することを指定します。
+ 2 番目のフィルターグループでは、正規表現 `READ_ME` に一致する Git 参照名を持つブランチで正規表現 `^refs/heads/.*` に一致する名前のファイルに対してプッシュリクエストが作成されることを指定します。
+ 3 番目のフィルタグループでは、正規表現 `\[CodeBuild\]` に一致する HEAD コミットメッセージを使用してプッシュリクエストを指定します。
+ 4 番目のフィルタグループは、正規表現 `\[CI-CodeBuild\]` に一致する CI/CD パイプライン名を持つ GitLab CI/CD パイプラインジョブリクエストを指定します。
```
CodeBuildProject:
Type: AWS::CodeBuild::Project
Properties:
Name: MyProject
ServiceRole: service-role
Artifacts:
Type: NO_ARTIFACTS
Environment:
Type: LINUX_CONTAINER
ComputeType: BUILD_GENERAL1_SMALL
Image: aws/codebuild/standard:5.0
Source:
Type: GITLAB
Location: source-location
Triggers:
Webhook: true
ScopeConfiguration:
Name: group-name
Scope: GITLAB_GROUP
FilterGroups:
- - Type: EVENT
Pattern: PULL_REQUEST_CREATED,PULL_REQUEST_UPDATED
- Type: BASE_REF
Pattern: ^refs/heads/main$
ExcludeMatchedPattern: false
- Type: ACTOR_ACCOUNT_ID
Pattern: 12345
ExcludeMatchedPattern: true
- - Type: EVENT
Pattern: PUSH
- Type: HEAD_REF
Pattern: ^refs/heads/.*
- Type: FILE_PATH
Pattern: READ_ME
ExcludeMatchedPattern: true
- - Type: EVENT
Pattern: PUSH
- Type: COMMIT_MESSAGE
Pattern: \[CodeBuild\]
- Type: FILE_PATH
Pattern: ^src/.+|^test/.+
- - Type: EVENT
Pattern: WORKFLOW_JOB_QUEUED
- Type: WORKFLOW_NAME
Pattern: \[CI-CodeBuild\]
```
# GitLab 手動ウェブフック
手動 GitLab ウェブフックを設定して、CodeBuild が GitLab 内で自動的にウェブフックを作成するのを防ぐことができます。CodeBuild は、ウェブフックを作成するための呼び出しの一部としてペイロード URL を返します。これを使用して、GitLab 内でウェブフックを手動で作成できます。GitLab アカウントでのウェブフックの作成を許可するリストに CodeBuild が登録されていない場合でも、ビルドプロジェクト用にウェブフックを手動で作成できます。
GitLab 手動ウェブフックを作成するには、次の手順に従います。
**GitLab 手動ウェブフックを作成するには**
1. AWS CodeBuild コンソール ([https://console.aws.amazon.com/codesuite/codebuild/home](https://console.aws.amazon.com/codesuite/codebuild/home)) を開きます。
1. ビルドプロジェクトを作成します。詳細については、「[ビルドプロジェクトの作成 (コンソール)](create-project.md#create-project-console)」および「[ビルドの実行 (コンソール)](run-build-console.md)」を参照してください。
+ [**Source (ソース)**] で、次のようにします。
+ **[ソースプロバイダ]** で **[GitLab]** を選択します。
+ **[リポジトリ]** では、**[GitLab アカウントのリポジトリ]** を選択します。
+ [**リポジトリの URL**] に、「**https://gitlab.com/*user-name*/*repository-name***」と入力します。
+ **[プライマリソースのウェブフックイベント]** の場合:
+ **[ウェブフック - オプション]** で、**[コードの変更がこのレポジトリにプッシュされるたびに再ビルド]** を選択します。
+ **[追加設定]** を選択し、**[手動作成 - オプション]** で、**[GitLab コンソールでこのリポジトリのウェブフックを手動で作成]** を選択します。
1. デフォルト値のまま続行し、**[ビルドプロジェクトを作成する]** を選択します。**[ペイロード URL]** と **[シークレット]** 値は後で使用するため、メモしておきます。
1. `https://gitlab.com/user-name/repository-name/-/hooks` で GitLab コンソールを開き、**[新しいウェブフックを追加]** を選択します。
+ **[URL]** には、先ほどメモしたペイロード URL 値を入力します。
+ **[シークレットトークン]** には、先ほどメモしたシークレット値を入力します。
+ CodeBuild にウェブフックペイロードを送信する個々のイベントを設定します。**[トリガー]** で、**[プッシュイベント]**、**[マージリクエストイベント]**、**[リリースイベント]**、**[ジョブイベント]** のいずれかのイベントを選択します。CodeBuild でサポートされているイベントタイプの詳細については、「[GitLab ウェブフックイベント](gitlab-webhook.md)」を参照してください。
1. **[ウェブフックを追加]** を選択します。
# GitLab ウェブフックイベント
ウェブフックフィルタグループを使用して、ビルドをトリガーする GitLab ウェブフックイベントを指定できます。たとえば、特定のブランチへの変更に対してのみビルドをトリガーするように指定できます。
ビルドをトリガーするウェブフックイベントを指定するには、ウェブフックフィルタグループを 1 つ以上作成できます。任意のフィルターグループが true と評価されると、ビルドがトリガーされます。これは、グループ内のすべてのフィルターが true と評価されたときに発生します。フィルタグループを作成する際、以下を指定します。
**イベント**
GitLab では、次のイベントのうち、1 つ以上を選択できます: `PUSH`、`PULL_REQUEST_CREATED`、`PULL_REQUEST_UPDATED`、`PULL_REQUEST_MERGED`、`PULL_REQUEST_REOPENED`、`PULL_REQUEST_CLOSED`、`RELEASED`、`WORKFLOW_JOB_QUEUED`。
ウェブフックのイベントタイプは、`X-GitLab-Event` フィールドのヘッダーに含まれています。次の表に、`X-GitLab-Event` ヘッダー値がイベントタイプにマッピングされる方法を示します。`Merge Request Hook` ウェブフックイベントの場合、ペイロードの `object_atttributes.action` にはマージリクエストタイプに関する追加情報が含まれます。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/gitlab-webhook.html)
`PULL_REQUEST_MERGED` の場合、プルリクエストがスカッシュ戦略とマージされ、プルリクエストブランチが閉じられると、元のプルリクエストコミットは存在しなくなります。この場合、`CODEBUILD_WEBHOOK_MERGE_COMMIT` 環境変数には、圧縮されたマージコミットの識別子が含まれます。
**1 つ以上のオプションフィルタ**
フィルタを指定するには、正規表現を使用します。ビルドをトリガーするイベントでは、関連付けられているグループ内のすべてのフィルターが true と評価される必要があります。
`ACTOR_ACCOUNT_ID` (コンソール内の `ACTOR_ID`)
GitLab アカウント ID が正規表現パターンと一致すると、ビルドがウェブフックイベントでトリガーされます。この値は、ウェブフックフィルタペイロードの `actor` オブジェクトの `account_id` プロパティに表示されます。
`HEAD_REF`
ヘッドリファレンスが正規表現パターンと一致すると (`refs/heads/branch-name` と `refs/tags/tag-name` など)、ウェブフックイベントによってビルドがトリガーされます。`HEAD_REF` フィルタは、ブランチまたはタグについて Git 参照名を評価します。ブランチ名またはタグ名は、ウェブフックペイロードの `push` オブジェクトにある、`new` オブジェクトの `name` フィールドに表示されます。プルリクエストイベントの場合、ブランチ名はウェブフックペイロードの `source` オブジェクトにある、`branch` オブジェクトの `name` フィールドに表示されます。
`BASE_REF`
基本参照が正規表現パターンと一致すると、ビルドがウェブフックイベントでトリガーされます。`BASE_REF` フィルタは、プルリクエストイベントでのみ使用できます (例: `refs/heads/branch-name`)。`BASE_REF` フィルタは、ブランチの Git 参照名を評価します。ブランチ名は、ウェブフックペイロードの `destination` オブジェクトにある、`branch` オブジェクトの `name` フィールドに表示されます。
`FILE_PATH`
変更されたファイルのパスが正規表現パターンに一致すると、ビルドが Webhook イベントでトリガーされます。
`COMMIT_MESSAGE`
HEAD コミットメッセージが正規表現パターンに一致する場合に、Webhook はビルドをトリガーします。
`WORKFLOW_NAME`
ワークフロー名が正規表現パターンに一致する場合に、ウェブフックはビルドをトリガーします。
**注記**
ウェブフックペイロードは、GitLab リポジトリのウェブフック設定で見つかります。
**Topics**
+ [
# GitLab ウェブフックイベントのフィルタリング (コンソール)
](gitlab-webhook-events-console.md)
+ [
# GitLab ウェブフックイベントのフィルタリング (SDK)
](gitlab-webhook-events-sdk.md)
+ [
# GitLab ウェブフックイベントのフィルタリング (CloudFormation)
](gitlab-webhook-events-cfn.md)
# GitLab ウェブフックイベントのフィルタリング (コンソール)
以下の手順に従って、 を使用してウェブフックイベント AWS マネジメントコンソール をフィルタリングします。GitLab ウェブフックイベントの詳細については、「[GitLab ウェブフックイベント](gitlab-webhook.md)」を参照してください。
1. プロジェクトの作成時に [**コードの変更がこのレポジトリにプッシュされるたびに再構築する**] を選択します。
1. [**イベントタイプ**] から、1 つ以上のイベントを選択します。
1. イベントでビルドをトリガーされた時間をフィルタリングするには、[**これらの条件でビルドを開始する**] で、1 つ以上のオプションフィルタを追加します。
1. イベントがトリガーされていない時間をフィルタリングするには、[**これらの条件でビルドを開始しない**] で、1 つ以上のオプションフィルタを追加します。
1. 別のフィルタグループを追加するには、[**フィルタグループの追加**] を選択します。
詳細については、「*AWS CodeBuild API リファレンス*」の「[ビルドプロジェクトの作成 (コンソール)](create-project.md#create-project-console)」および「[WebhookFilter](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_WebhookFilter.html)」を参照してください。
この例では、ウェブフックフィルタグループは、プルリクエストに対してのみビルドをトリガーします。
![\[プルリクエストのみのビルドをトリガーするウェブフックフィルタグループ。\]](http://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/images/pull-request-webhook-filter-gitlab.png)
2 つのフィルタグループの例を使用した場合、ビルドは一方または両方が true と評価されるとトリガーされます。
+ 最初のフィルタグループでは、正規表現 `^refs/heads/main$` に一致する Git 参照と `^refs/heads/branch1!` に一致するヘッド参照を含むブランチで作成または更新されたプルリクエストを指定します。
+ 2 番目のフィルタグループでは、正規表現 `^refs/heads/branch1$` に一致する Git 参照を含むブランチでプッシュリクエストを指定します。
![\[2 つのフィルタグループの例です。\]](http://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/images/pull-request-webhook-filter-head-base-regexes-gitlab.png)
この例では、ウェブフックフィルタグループは、タグイベントを除くすべてのリクエストに対してビルドをトリガーします。
![\[タグイベントを除くすべてのリクエストに対してビルドをトリガーする、ウェブフックフィルタグループです。\]](http://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/images/pull-request-webhook-filter-exclude-gitlab.png)
この例では、ウェブフックフィルタグループは、正規表現 `^buildspec.*` に一致する名前のファイルが変更された場合にのみビルドをトリガーします。
![\[指定された正規表現に一致する名前のファイルに対してのみビルドをトリガーする、ウェブフックフィルタグループです。\]](http://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/images/pull-request-webhook-filter-file-name-regex-gitlab.png)
この例で、Webhook フィルターグループは、ファイルが `src` または `test` フォルダーで変更された場合にのみ、ビルドをトリガーします。
![\[指定されたフォルダ内でファイルが変更された場合にのみビルドをトリガーする、ウェブフックフィルタグループです。\]](http://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/images/pull-request-webhook-filter-file-name-combined-regex-gitlab.png)
この例では、正規表現 `actor-account-id` と一致するアカウント ID を持たない GitLab ユーザーが変更を行った場合にのみ、ウェブフックフィルタグループがビルドをトリガーします。
**注記**
GitLab アカウント ID の検索方法については、「https://api.github.com/users/*user-name*」を参照してください。ここで、*user-name* は、GitLab のユーザー名を表します。
![\[アカウント ID を持たない GitLab ユーザーが変更を行った場合にのみビルドをトリガーする、ウェブフックフィルタグループです。\]](http://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/images/pull-request-webhook-filter-actor-gitlab.png)
この例では、HEAD コミットメッセージが正規表現 `\[CodeBuild\]` に一致する場合に、Webhook フィルタグループがプッシュイベントのビルドをトリガーします。
![\[HEAD コミットメッセージが正規表現に一致する場合に、プッシュイベントのビルドをトリガーするウェブフックフィルタグループです。\]](http://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/images/pull-request-webhook-filter-commit-message-gitlab.png)
# GitLab ウェブフックイベントのフィルタリング (SDK)
AWS CodeBuild SDK を使用してウェブフックイベントをフィルタリングするには、 `CreateWebhook`または `UpdateWebhook` API メソッドのリクエスト構文で `filterGroups`フィールドを使用します。詳細については、*CodeBuild API リファレンス*の「[WebhookFilter](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_WebhookFilter.html)」を参照してください。
GitLab ウェブフックイベントの詳細については、「[GitLab ウェブフックイベント](gitlab-webhook.md)」を参照してください。
プルリクエストに対してのみビルドをトリガーするウェブフックフィルタを作成するには、以下をリクエスト構文に挿入します。
```
"filterGroups": [
[
{
"type": "EVENT",
"pattern": "PULL_REQUEST_CREATED, PULL_REQUEST_UPDATED, PULL_REQUEST_MERGED"
}
]
]
```
指定されたブランチに対してのみビルドをトリガーするウェブフックフィルタを作成するには、`pattern` パラメータを使用して、ブランチ名をフィルタリングするよう正規表現を指定します。2 つのフィルタグループの例を使用した場合、ビルドは一方または両方が true と評価されるとトリガーされます。
+ 最初のフィルタグループでは、正規表現 `^refs/heads/main$` に一致する Git 参照と `^refs/heads/myBranch$` に一致するヘッド参照を含むブランチで作成または更新されたプルリクエストを指定します。
+ 2 番目のフィルタグループでは、正規表現 `^refs/heads/myBranch$` に一致する Git 参照を含むブランチでプッシュリクエストを指定します。
```
"filterGroups": [
[
{
"type": "EVENT",
"pattern": "PULL_REQUEST_CREATED, PULL_REQUEST_UPDATED"
},
{
"type": "HEAD_REF",
"pattern": "^refs/heads/myBranch$"
},
{
"type": "BASE_REF",
"pattern": "^refs/heads/main$"
}
],
[
{
"type": "EVENT",
"pattern": "PUSH"
},
{
"type": "HEAD_REF",
"pattern": "^refs/heads/myBranch$"
}
]
]
```
`excludeMatchedPattern` パラメータを使用すると、ビルドをトリガーしないイベントを指定することができます。この例では、ビルドは、タグイベントを除くすべてのリクエストに対してトリガーされます。
```
"filterGroups": [
[
{
"type": "EVENT",
"pattern": "PUSH, PULL_REQUEST_CREATED, PULL_REQUEST_UPDATED, PULL_REQUEST_MERGED"
},
{
"type": "HEAD_REF",
"pattern": "^refs/tags/.*",
"excludeMatchedPattern": true
}
]
]
```
アカウント ID `actor-account-id` を持つ GitLab ユーザーによって変更が行われた場合にのみビルドをトリガーするフィルタを作成できます。
**注記**
GitLab アカウント ID の検索方法については、「https://api.github.com/users/*user-name*」を参照してください。ここで、*user-name* は、GitLab のユーザー名を表します。
```
"filterGroups": [
[
{
"type": "EVENT",
"pattern": "PUSH, PULL_REQUEST_CREATED, PULL_REQUEST_UPDATED, PULL_REQUEST_MERGED"
},
{
"type": "ACTOR_ACCOUNT_ID",
"pattern": "actor-account-id"
}
]
]
```
引数 `pattern` の正規表現に一致する名前のファイルが変更される場合にのみビルドをトリガーするフィルタを作成することができます。この例のフィルタグループでは、正規表現 `^buildspec.*` に一致する名前のファイルが変更された場合にのみビルドをトリガーするよう指定します。
```
"filterGroups": [
[
{
"type": "EVENT",
"pattern": "PUSH"
},
{
"type": "FILE_PATH",
"pattern": "^buildspec.*"
}
]
]
```
この例で、フィルターグループは、ファイルが `src` または `test` フォルダーで変更された場合にのみ、ビルドをトリガーするように指定しています。
```
"filterGroups": [
[
{
"type": "EVENT",
"pattern": "PUSH"
},
{
"type": "FILE_PATH",
"pattern": "^src/.+|^test/.+"
}
]
]
```
HEAD コミットメッセージがパターン引数の正規表現に一致する場合にのみビルドをトリガーするフィルタを作成できます。この例のフィルタグループでは、プッシュイベントの HEAD コミットメッセージが正規表現 `\[CodeBuild\]` に一致する場合にのみビルドをトリガーするよう指定します。
```
"filterGroups": [
[
{
"type": "EVENT",
"pattern": "PUSH"
},
{
"type": "COMMIT_MESSAGE",
"pattern": "\[CodeBuild\]"
}
]
]
```
# GitLab ウェブフックイベントのフィルタリング (CloudFormation)
CloudFormation テンプレートを使用してウェブフックイベントをフィルタリングするには、 AWS CodeBuild プロジェクトの `FilterGroups`プロパティを使用します。GitLab ウェブフックイベントの詳細については、「[GitLab ウェブフックイベント](gitlab-webhook.md)」を参照してください。
以下の YAML 形式の CloudFormation テンプレート部分によって、2 つのフィルタグループが作成されます。また、一方または両方が true と評価されると、ビルドがトリガーされます。
+ 最初のフィルタグループでは、アカウント ID `12345` を持たない GitLab ユーザーが、正規表現 `^refs/heads/main$` と一致する Git 参照名を持つブランチに対してプルリクエストを作成または更新することを指定します。
+ 2 番目のフィルタグループでは、正規表現 `^refs/heads/.*` と一致する Git 参照名を持つブランチに対するプッシュリクエストを作成することを指定します。
+ 3 番目のフィルタグループでは、正規表現 `\[CodeBuild\]` に一致する HEAD コミットメッセージを使用してプッシュリクエストを指定します。
+ 4 番目のフィルタグループは、正規表現 `\[CI-CodeBuild\]` に一致するワークフロー名を持つ GitHub Actions ワークフロージョブリクエストを指定します。
```
CodeBuildProject:
Type: AWS::CodeBuild::Project
Properties:
Name: MyProject
ServiceRole: service-role
Artifacts:
Type: NO_ARTIFACTS
Environment:
Type: LINUX_CONTAINER
ComputeType: BUILD_GENERAL1_SMALL
Image: aws/codebuild/standard:5.0
Source:
Type: GITLAB
Location: source-location
Triggers:
Webhook: true
FilterGroups:
- - Type: EVENT
Pattern: PULL_REQUEST_CREATED,PULL_REQUEST_UPDATED
- Type: BASE_REF
Pattern: ^refs/heads/main$
ExcludeMatchedPattern: false
- Type: ACTOR_ACCOUNT_ID
Pattern: 12345
ExcludeMatchedPattern: true
- - Type: EVENT
Pattern: PUSH
- Type: HEAD_REF
Pattern: ^refs/heads/.*
- - Type: EVENT
Pattern: PUSH
- Type: COMMIT_MESSAGE
Pattern: \[CodeBuild\]
- - Type: EVENT
Pattern: WORKFLOW_JOB_QUEUED
- Type: WORKFLOW_NAME
Pattern: \[CI-CodeBuild\]
```
# Buildkite 手動ウェブフック
現在のところ、CodeBuild では、すべての Buildkite ウェブフックを手動で作成する必要があります。CodeBuild は、ウェブフックを作成するための呼び出しの一部としてペイロード URL を返します。これを使用して、Buildkite 内でウェブフックを手動で作成できます。
Buildkite 手動ウェブフックを作成するには、次の手順に従います。
**ウェブフックを使用して CodeBuild プロジェクトを作成するには**
1. AWS CodeBuild コンソール ([https://console.aws.amazon.com/codesuite/codebuild/home](https://console.aws.amazon.com/codesuite/codebuild/home)) を開きます。
1. ビルドプロジェクトを作成します。詳細については、「[ビルドプロジェクトの作成 (コンソール)](create-project.md#create-project-console)」および「[ビルドの実行 (コンソール)](run-build-console.md)」を参照してください。
1. **[プロジェクトの設定]** で、**[ランナープロジェクト]** を選択します。
**[ランナー]** で、次のようにします。
+ **[ランナープロバイダー]** で、**[Buildkite]** を選択します。
+ **[Buildkite エージェントトークン]** で、**[シークレットの作成ページを使用して新しいエージェントトークンを作成する]** を選択します。上記で生成した Buildkite エージェントトークンと等しいシークレット値を持つ新しいシークレットを AWS Secrets Manager で作成するように求められます。
+ (オプション) ジョブに CodeBuild マネージド認証情報を使用する場合は、**[Buildkite ソース認証情報オプション]** でジョブのソースリポジトリプロバイダーを選択し、アカウントに認証情報が設定されていることを確認します。さらに、Buildkite パイプラインで **HTTPS を使用したチェックアウト**が使用されていることを確認します。
1.
+ [**環境**] で以下の操作を行います。
+ サポートされている **[環境イメージ]** と **[コンピューティング]** を選択します。GitHub Actions ワークフロー YAML のラベルを使用して、イメージとインスタンスの設定を上書きするオプションがあることに注意してください。詳細については、「[ステップ 2: GitHub Actions ワークフロー YAML を更新](action-runner.md#sample-github-action-runners-update-yaml)」を参照してください。
+ [**Buildspec (Buildspec)**] で、次のようにします。
+ `buildspec-override:true` がラベルとして追加されない限り、buildspec は無視されることに注意してください。代わりに、CodeBuild は、セルフホスト型ランナーを設定するコマンドを使用するように上書きします。
1. デフォルト値のまま続行し、**[ビルドプロジェクトを作成する]** を選択します。
1. **[ウェブフックの作成]** ポップアップから **[ペイロードの URL]** と **[シークレット]** の値を保存します。ポップアップの手順に従って、新しい Buildkite 組織のウェブフックを作成します。
# プルリクエストコメントの承認
CodeBuild は、プルリクエストによってトリガーされるビルドをさらに制御するプルリクエストビルドポリシーをサポートしています。不明なユーザーからのプルリクエストは、変更がレビュー可能になるまで自動的に構築しないのが理想的です。この機能を使用すると、チームメンバーの 1 人に、まずコードを確認してからパイプラインを実行するよう要求できます。これは、不明なコントリビューターによって送信されたコードを構築する際のセキュリティ対策としてよく使用されます。
プルリクエストビルドポリシーを使用すると、コントリビューターのアクセス許可と承認ステータスに基づいて CodeBuild がプルリクエストのビルドをトリガーするタイミングを制御できます。これは、外部コラボレーターからのコントリビューションを受け入れるパブリックリポジトリまたはリポジトリにとって特に重要です。
この機能を有効にすると、次のいずれかの場合にのみプルリクエストに対してビルドがトリガーされます。
+ プルリクエストが、信頼できるコントリビューターによって作成された。
+ 信頼されたコントリビューターが、特定のコメントを投稿してプルリクエストを承認した。
## 仕組み
**信頼できるコントリビューター**
信頼できるコントリビューターは、ソース管理システムの現在のロールがプルリクエストベースのポリシーで承認者ロールとして設定されているユーザーです。信頼できるコントリビューターがプルリクエストを作成すると、CodeBuild はビルドを自動的にトリガーし、現在の動作を維持します。
**信頼できないコントリビューター**
信頼できないコントリビューターは、承認者ロールのリストにロールが設定されていないユーザーです。信頼できないコントリビューターがプルリクエストを作成した場合:
1. CodeBuild は、ビルドステータスを「失敗」とマークし、「ビルドの開始に必要なプルリクエストの承認」というメッセージを表示します。
1. 信頼されたコントリビューターが変更を確認し、`/codebuild_run()` にコメントを投稿してビルドをトリガーする必要があります。例えば、`/codebuild_run(046e8b67481d53bdc86c3f6affdd5d1afae6d369)`。
1. CodeBuild はコメンダーのアクセス許可を検証し、承認されるとビルドをトリガーします。
1. ビルド結果がプルリクエストページで報告されます。
**コメント承認構文**
信頼できるコントリビューターは、次のコメント形式を使用してビルドを承認できます。
+ `/codebuild_run(046e8b67481d53bdc86c3f6affdd5d1afae6d369)` - 指定されたコミット SHA に基づいてビルドをトリガーします。
## 構成
**デフォルトの 動作**
プルリクエストビルドポリシーは、新しく作成されたすべての CodeBuild プロジェクトでデフォルトで有効になっています。
**API パラメータ**
プルリクエストのビルドポリシーは、次のアクションで `PullRequestBuildPolicy` パラメータを使用して設定されます。
+ `CreateWebhook`
+ `UpdateWebhook`
**`PullRequestBuildPolicy` の構造**
```
{
"requiresCommentApproval": "string",
"approverRoles": ["string", ...]
}
```
**`requiresCommentApproval`**
プルリクエストでビルドをトリガーする前に、コメントベースの承認が必要なタイミングを指定します。この設定では、ビルドを自動的に実行するか、コメントによる明示的な承認を必要とするかが決まります。
タイプ: 文字列
有効な値:
+ `DISABLED` - コメントの承認を必要とせずにトリガーを自動的に構築します。
+ `FORK_PULL_REQUESTS` - フォークされたリポジトリからのプルリクエストにのみコメントの承認が必要です (コントリビューターがいずれかの承認者ロールである場合を除く)。
+ `ALL_PULL_REQUESTS` - すべてのプルリクエストに、ビルドの実行前にコメントの承認が必要です (コントリビューターがいずれかの承認者ロールである場合を除く)。これは、デフォルト値です。
**`approverRoles`**
コメントの承認が必要な場合にプルリクエストビルドの承認権限を持つリポジトリロールのリスト。これらのロールを持つユーザーのみが有効なコメント承認を行うことができます。プルリクエストコントリビューターがこれらのロールのいずれかである場合、そのプルリクエストビルドは自動的にトリガーされます。
型: 文字列の配列
GitHub プロジェクトの有効な値 (値は GitHub ロールにマッピングされます)。
+ `GITHUB_ADMIN` - リポジトリ管理者
+ `GITHUB_MAINTAIN` - リポジトリメンテナンス担当者
+ `GITHUB_WRITE` - 書き込みアクセス許可を持つユーザー
+ `GITHUB_TRIAGE` - トリアージアクセス許可を持つユーザー
+ `GITHUB_READ` - 読み取りアクセス許可を持つユーザー
+ デフォルト: `["GITHUB_ADMIN", "GITHUB_MAINTAINER", "GITHUB_WRITE"]`
GitLab プロジェクトの有効な値 (値は GitLab ロールにマッピングされます)。
+ `GITLAB_OWNER` - リポジトリ所有者
+ `GITLAB_MAINTAINER` - リポジトリメンテナンス担当者
+ `GITLAB_DEVELOPER` - 開発者アクセス許可を持つユーザー
+ `GITLAB_REPORTER` - 報告者アクセス許可を持つユーザー
+ `GITLAB_PLANNER` - プランナーアクセス許可を持つユーザー
+ `GITLAB_GUEST ` - ゲストアクセス許可を持つユーザー
+ デフォルト: `["GITLAB_OWNER", "GITLAB_MAINTAINER", "GITLAB_DEVELOPER"]`
Bitbucket プロジェクトの有効な値 (値は Bitbucket ロールにマッピングされます)。
+ `BITBUCKET_ADMIN ` - リポジトリ管理者
+ `BITBUCKET_WRITE` - 書き込みアクセス許可を持つユーザー
+ `BITBUCKET_READ ` - 読み取りアクセス許可を持つユーザー
+ デフォルト: `["BITBUCKET_ADMIN", "BITBUCKET_WRITE"]`
## 例
**すべてのプルリクエストのコメント承認を有効にする**
AWS CodeBuild SDK を使用してウェブフックのプルリクエストビルドポリシーを有効または無効にするには、 `CreateWebhook` または `UpdateWebhook` API メソッドのリクエスト構文で `pullRequestBuildPolicy`フィールドを使用します。詳細については、*CodeBuild API リファレンス*の「[WebhookFilter](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_WebhookFilter.html)」を参照してください。
Github ロール「管理者」、「メンテナンス」、「書き込み」を持つユーザーが、信頼できるコントリビューターとして扱われます。
```
"pullRequestBuildPolicy": {
"requiresCommentApproval": "ALL_PULL_REQUESTS",
"approverRoles": ["GITHUB_ADMIN", "GITHUB_MAINTAIN", "GITHUB_WRITE"]
}
```
**リポジトリ管理者およびメンテナンス担当者に対してのみコメント承認を有効にする**
GitHub ロール「管理者」、「メンテナンス」を持つユーザーが、信頼できるコントリビューターとして扱われます。
```
"pullRequestBuildPolicy": {
"requiresCommentApproval": "FORK_PULL_REQUESTS",
"approverRoles": ["GITHUB_ADMIN", "GITHUB_MAINTAINER"]
}
```
**コメント承認を無効にする**
```
"pullRequestBuildPolicy": {
"requiresCommentApproval": "DISABLED"
}
```
## AWS CloudFormation
AWS CloudFormation テンプレートを使用してウェブフックのプルリクエストビルドポリシーを有効または無効にするには、PullRequestBuildPolicy プロパティを使用します。 AWS CloudFormation テンプレートの次の YAML 形式の部分は、すべてのプルリクエストに対してプルリクエストビルドポリシーが有効になっているウェブフックを持つプロジェクトを作成します。承認者として指定されたメンテナンスロールと管理者ロール。
```
CodeBuildProject:
Type: AWS::CodeBuild::Project
Properties:
Name: MyProject
ServiceRole: service-role
Artifacts:
Type: NO_ARTIFACTS
Environment:
Type: LINUX_CONTAINER
ComputeType: BUILD_GENERAL1_SMALL
Image: aws/codebuild/standard:5.0
Source:
Type: BITBUCKET
Location: source-location
Triggers:
Webhook: true
FilterGroups:
- - Type: EVENT
Pattern: PULL_REQUEST_CREATED,PULL_REQUEST_UPDATED
- Type: BASE_REF
Pattern: ^refs/heads/main$
ExcludeMatchedPattern: false
PullRequestBuildPolicy:
RequiresCommentApproval: ALL_PULL_REQUESTS
ApproverRoles:
- GITHUB_MAINTAIN
- GITHUB_ADMIN
```
## コンソール設定
AWS マネジメントコンソールを使用してウェブフックイベントをフィルタリングするには:
1. [**コメント承認**] では、すべてのプルリクエスト (`ALL_PULL_REQUEST`) に対して無効または有効、またはフォークからのプルリクエスト (`FORK_PULL_REQUEST`) に対してのみ有効を選択します。
1. [**承認者ロール**] では、コメントの承認が必要な場合にプルリクエストビルドの承認権限を持つリポジトリロールを選択します。
詳細については、「*CodeBuild API リファレンス*」の「[ビルドプロジェクトの作成 (コンソール)](create-project.md#create-project-console)」および「[WebhookFilter](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_WebhookFilter.html)」を参照してください。
![\[コメント承認付きのプライマリソースウェブフックイベントコンソール。\]](http://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/images/pull-request-comment-approval.png)
# でビルドプロジェクトの詳細を表示する AWS CodeBuild
AWS CodeBuild コンソール AWS CLI、または AWS SDKs を使用して、CodeBuild でビルドプロジェクトの詳細を表示できます。
**Topics**
+ [
## ビルドプロジェクトの詳細を表示する (コンソール)
](#view-project-details-console)
+ [
## ビルドプロジェクトの詳細を表示する (AWS CLI)
](#view-project-details-cli)
+ [
## ビルドプロジェクトの詳細を表示する (AWS SDKs)
](#view-project-details-sdks)
## ビルドプロジェクトの詳細を表示する (コンソール)
1. [https://console.aws.amazon.com/codesuite/codebuild/home](https://console.aws.amazon.com/codesuite/codebuild/home) で AWS CodeBuild コンソールを開きます。
1. ナビゲーションペインで、[**Build projects**] を選択します。
**注記**
デフォルトでは、最新の 10 個のビルドプロジェクトのみが表示されます。さらに多くのビルドプロジェクトを表示するには、歯車アイコンを選択して [**Projects per page (ページ毎プロジェクト数)**] で別の値を選択するか、前後の矢印を使用します。
1. ビルドプロジェクトのリストの [**名前**] 列で、ビルドプロジェクトのリンクを選択します。
1. [**ビルドプロジェクト: *project-name***] ページで、[**ビルドの詳細**] を選択します。
## ビルドプロジェクトの詳細を表示する (AWS CLI)
**batch-get-projects** コマンドを実行します。
```
aws codebuild batch-get-projects --names names
```
上記のコマンドで、次のプレースホルダを置き換えます。
+ *names*: 詳細を表示する 1 つ以上のビルドプロジェクト名を示すのに必要な文字列。複数のビルドプロジェクトを指定するには、各ビルドプロジェクトの名前をスペースで区切ります。最大 100 のビルドプロジェクト名を指定できます。ビルドプロジェクトのリストを表示するには、「[ビルドプロジェクト名の一覧表示 (AWS CLI)](view-project-list.md#view-project-list-cli)」を参照してください。
たとえば、次のコマンドを実行するとします。
```
aws codebuild batch-get-projects --names codebuild-demo-project codebuild-demo-project2 my-other-demo-project
```
次のような結果が出力に表示されます。省略記号 (`...`) は簡潔にするために省略されたデータを表すのに使用されます。
```
{
"projectsNotFound": [
"my-other-demo-project"
],
"projects": [
{
...
"name": codebuild-demo-project,
...
},
{
...
"name": codebuild-demo-project2",
...
}
]
}
```
上記の出力では、指定されたビルドプロジェクト名はすべて `projectsNotFound` 配列にリストされていますが、情報は見つかりませんでした。`projects` 配列は、情報が見つかった各ビルドプロジェクトの詳細を示しています。ビルドプロジェクトの詳細は、簡潔にするために前の出力から省略されています。詳細については、「[ビルドプロジェクトの作成 (AWS CLI)](create-project.md#create-project-cli)」の出力を参照してください。
**batch-get-projects** コマンドは、特定のプロパティ値のフィルタリングをサポートしていませんが、プロジェクトのプロパティを列挙するスクリプトを記述できます。たとえば、次の Linux シェルスクリプトは、現在のアカウントの現在のリージョンのプロジェクトを列挙し、各プロジェクトで使用されるイメージを出力します。
```
#!/usr/bin/sh
# This script enumerates all of the projects for the current account
# in the current region and prints out the image that each project is using.
imageName=""
function getImageName(){
local environmentValues=(${1//$'\t'/ })
imageName=${environmentValues[1]}
}
function processProjectInfo() {
local projectInfo=$1
while IFS=$'\t' read -r section value; do
if [[ "$section" == *"ENVIRONMENT"* ]]; then
getImageName "$value"
fi
done <<< "$projectInfo"
}
# Get the list of projects.
projectList=$(aws codebuild list-projects --output=text)
for projectName in $projectList
do
if [[ "$projectName" != *"PROJECTS"* ]]; then
echo "==============================================="
# Get the detailed information for the project.
projectInfo=$(aws codebuild batch-get-projects --output=text --names "$projectName")
processProjectInfo "$projectInfo"
printf 'Project "%s" has image "%s"\n' "$projectName" "$imageName"
fi
done
```
AWS CLI で を使用する方法の詳細については AWS CodeBuild、「」を参照してください[コマンドラインリファレンス](cmd-ref.md)。
## ビルドプロジェクトの詳細を表示する (AWS SDKs)
SDK AWS CodeBuild で を使用する方法の詳細については、「」を参照してください[AWS SDKsとツールのリファレンス](sdk-ref.md)。 AWS SDKs
# でビルドプロジェクト名を表示する AWS CodeBuild
AWS CodeBuild コンソール AWS CLI、、または AWS SDKs を使用して、CodeBuild でビルドプロジェクトのリストを表示できます。
**Topics**
+ [
## ビルドプロジェクト名の一覧表示 (コンソール)
](#view-project-list-console)
+ [
## ビルドプロジェクト名の一覧表示 (AWS CLI)
](#view-project-list-cli)
+ [
## ビルドプロジェクト名 (AWS SDKsのリストを表示する
](#view-project-list-sdks)
## ビルドプロジェクト名の一覧表示 (コンソール)
コンソールの AWS リージョンでビルドプロジェクトのリストを表示できます。この情報には、名前、ソースプロバイダー、リポジトリ、最新のビルドステータス、説明 (ある場合) が含まれます。
1. [https://console.aws.amazon.com/codesuite/codebuild/home](https://console.aws.amazon.com/codesuite/codebuild/home) で AWS CodeBuild コンソールを開きます。
1. ナビゲーションペインで、[**Build projects**] を選択します。
**注記**
デフォルトでは、最新の 10 個のビルドプロジェクトのみが表示されます。さらに多くのビルドプロジェクトを表示するには、歯車アイコンを選択して [**Projects per page (ページ毎プロジェクト数)**] で別の値を選択するか、前後の矢印を使用します。
## ビルドプロジェクト名の一覧表示 (AWS CLI)
**list-projects** コマンドを実行します。
```
aws codebuild list-projects --sort-by sort-by --sort-order sort-order --next-token next-token
```
上記のコマンドで、次のプレースホルダを置き換えます。
+ *sort-by*: ビルドプロジェクト名を一覧表示するために使用する条件を示すためのオプションの文字列。有効な値を次に示します。
+ `CREATED_TIME`: 各ビルドプロジェクトがいつ作成されたかに基づいて、ビルドプロジェクト名を一覧表示します。
+ `LAST_MODIFIED_TIME`: 各ビルドプロジェクトに関する情報が最後に変更されたときに基づいてビルドプロジェクト名を一覧表示します。
+ `NAME` 各ビルドプロジェクト名に基づいて、ビルドプロジェクト名を一覧表示します。
+ *sort-order*: ビルドプロジェクトのリストを表示するためのオプションの文字列。*sort-by* に基づく。有効な値は、`ASCENDING` および `DESCENDING` です。
+ *next-token*: オプションの文字列。以前の実行中に、リストに 100 を超える項目がある場合、最初の 100 項目だけが、*next token* と呼ばれる一意の文字列と共に返されます。リスト内の項目の次のバッチを取得するには、次のコマンドを再度実行し、次のトークンを呼び出しに追加します。リスト内のすべての項目を取得するには、次のトークンが返されなくなるまで、このコマンドを、以後のすべての次のトークンで実行し続けます。
たとえば、次のコマンドを実行するとします。
```
aws codebuild list-projects --sort-by NAME --sort-order ASCENDING
```
次のような結果が出力に表示されることがあります。
```
{
"nextToken": "Ci33ACF6...The full token has been omitted for brevity...U+AkMx8=",
"projects": [
"codebuild-demo-project",
"codebuild-demo-project2",
... The full list of build project names has been omitted for brevity ...
"codebuild-demo-project99"
]
}
```
このコマンドをもう一度実行します。
```
aws codebuild list-projects --sort-by NAME --sort-order ASCENDING --next-token Ci33ACF6...The full token has been omitted for brevity...U+AkMx8=
```
次のような結果が出力に表示されることがあります。
```
{
"projects": [
"codebuild-demo-project100",
"codebuild-demo-project101",
... The full list of build project names has been omitted for brevity ...
"codebuild-demo-project122"
]
}
```
## ビルドプロジェクト名 (AWS SDKsのリストを表示する
SDK AWS CodeBuild で を使用する方法の詳細については、「」を参照してください[AWS SDKsとツールのリファレンス](sdk-ref.md)。 AWS SDKs