Cloud Build Pub/Sub トリガーを使用すると、Pub/Sub で公開された Google Cloud イベントに応答してビルドを実行できます。Pub/Sub イベントの情報を使用してビルドをパラメータ化し、イベントに応答してビルドを実行するかどうかを決定できます。Pub/Sub トリガーは、任意の Pub/Sub トピックをリッスンするように構成できます。
このページでは、Artifact Registry、Container Registry、および Cloud Storage 上のイベントに応じてビルドを自動化する Pub/Sub トリガーを作成する方法について説明します。
始める前に
-
Cloud Build API を有効にします。
- ソースコードにリポジトリ内のビルド構成ファイルまたは
Dockerfileが含まれていることを確認します。 このページで
gcloudコマンドを使用するには、Google Cloud CLI をインストールします。
Artifact Registry イベントに応答するビルドトリガーを作成する
イメージが push、タグ付け、削除された場合などの Artifact Registry イベントに応答する Pub/Sub トリガーを作成できます。このセクションでは、新しいタグが既存のイメージに push されたときにビルドを起動する Pub/Sub トリガーを作成する方法について説明します。Artifact Registry に習熟されていない場合は、Artifact Registry の概要をご覧ください。
コンソール
Google Cloud Console を使用して、Artifact Registry の既存のイメージに push された新しいタグをリッスンするトリガーを作成するには、次のとおり操作します。
[トリガー] ページを開く
ページ上部でプロジェクトを選択し、[開く] をクリックします。
[トリガーを作成] をクリックします。
次のトリガー設定を入力します。
- 名前: トリガーの名前を入力します。
リージョン: トリガーのリージョンを選択します。
- リージョンとしてグローバルを選択した場合、Cloud Build はビルドを実行するためにデフォルトのプールを使用します。
- 非グローバル リージョンを選択して、トリガーに関連付けられたビルド構成ファイルでプライベート プールを指定すると、Cloud Build はプライベート プールを使用してビルドを実行します。この場合、トリガーで指定するリージョンは、プライベート プールを作成したリージョンと一致する必要があります。
- 非グローバル リージョンを選択し、トリガーに関連付けられたビルド構成ファイルでプライベート プールが指定されていない場合、Cloud Build はデフォルトのプールを使用してトリガーと同じリージョンでビルドを実行します。
説明（省略可）: トリガーの説明を入力します。
イベント: トリガーを起動するイベントとして [Pub/Sub メッセージ] を選択します。
サブスクリプション: トリガー イベントとして登録する Pub/Sub トピックを選択します。プロジェクトの既存のトピックがすべてプルダウン メニューに表示されます。
- Pub/Sub トピック: プルダウン メニューから
gcrトピックを選択するか、Pub/Sub 通知の構成の手順でトピックを手動で作成します。
- Pub/Sub トピック: プルダウン メニューから
ソース: ソースとして [第 1 世代] を選択します。
リポジトリ: 使用可能なリポジトリのリストから目的のリポジトリを選択します。
ブランチまたはタグ: ブランチまたはタグの値にマッチングさせる正規表現を指定します。有効な正規表現の構文については、RE2 構文をご覧ください。
コメント制御: イベントとして pull リクエスト（GitHub アプリのみ）を選択した場合は、ビルドをトリガーによって自動的に実行するかどうか、次のいずれかのオプションを選択します。
Required except for owners and collaborators: pull リクエストがリポジトリ所有者または共同編集者によって作成または更新されると、ビルドが自動的にトリガーによって実行されます。外部の投稿者がアクションを開始する場合、その pull リクエストで所有者または共同編集者が
/gcbrunにコメントした後にのみビルドが実行されます。必須: 投稿者を問わず pull リクエストが作成または更新されると、所有者または共同編集者が pull リクエストに
/gcbrunとコメントした後にのみビルドが実行されます。ビルドは、pull リクエストが変更されるたびに実行されます。不要: 投稿者を問わず pull リクエストが作成または更新されると、ビルドが自動的にトリガーで実行されます。
構成: ビルドに使用するリモート リポジトリにあるビルド構成ファイルを選択するか、インライン ビルド構成ファイルを作成します。
- タイプ: ビルドに使用する構成のタイプを選択します。
- Cloud Build 構成ファイル（yaml または json）: 構成にビルド構成ファイルを使用します。
- Dockerfile: 構成には
Dockerfileを使用します。 - Buildpacks: 構成には Buildpacks を使用します。
場所: 構成の場所を指定します。
- リポジトリ: 構成ファイルがリモート リポジトリにある場合は、ビルド構成ファイル、
Dockerfileディレクトリの場所、または Bullpack のディレクトリを指定します。ビルド構成タイプがDockerfileまたは buildpack の場合、ビルドするイメージの名前と、必要に応じてビルドのタイムアウトを指定する必要があります。Dockerfileまたは buildpack イメージ名を指定すると、ビルドが実行されるdocker buildまたはpackコマンドのプレビューが表示されます。 - buildpack の環境変数（省略可）: 構成タイプとして
buildpacksを選択した場合、[パック環境変数を追加] をクリックして buildpack 環境変数と値を指定します。buildpack 環境変数の詳細については、環境変数をご覧ください。 インライン: 構成オプションとして Cloud Build 構成ファイル（yaml または json）を選択した場合、インライン ビルド構成を指定できます。Google Cloud Console で [エディタを開く] をクリックして、YAML または JSON 構文でビルド構成ファイルを書き込みます。[完了] をクリックしてビルド構成ファイルを保存します。
- リポジトリ: 構成ファイルがリモート リポジトリにある場合は、ビルド構成ファイル、
- タイプ: ビルドに使用する構成のタイプを選択します。
代入変数（省略可）: ビルド構成のオプションとしてビルド構成ファイルを選択した場合、このフィールドを使用してトリガー固有の代入変数を定義できます。
次の例では、ペイロードからイメージタグの名前を取得し、さらに
gcrイベントに関連付けられたアクションを取得します。これを行うには、ペイロード バインディングを使用して置換変数を作成します。以下の変数と値を指定します。
変数の名前 変数の値 _IMAGE_TAG$(body.message.data.tag)_ACTION$(body.message.data.action)body.messageは、パブリッシャーによってパブリッシュされ、サブスクライバーによって使用される PubSubMessage を参照します。Pub/Sub 通知ペイロードに関するその他の例については、通知の例をご覧ください。フィルタ（省略可）: 置換変数にフィルタを指定することで、受信したペイロードに応じて、トリガーによってビルドを実行するかどうかを決定するフィルターをトリガー内に作成できます。ビルドを実行するには、フィルタ式が
trueに評価される必要があります。複数のメッセージがあるトピックで Pub/Sub トリガーを設定する場合は、フィルタリングを使用することをおすすめします。フィルタを使用すると、受信する Pub/Sub メッセージに応答して実行されるビルドをきめ細やかに制御できます。フィルタを使用しないトリガーの設定に関連するリスクについては、フィルタされていないトリガーに関連するリスクをご覧ください。
次の例では、新しいタグが既存のイメージに push された場合にトリガーがビルドを実行するようにしています。フィルタ条件演算子を使用して、
_IMAGE_TAG変数が既存のタグ名と一致しているかどうかを確認し、新しく追加されたデータを探すために_ACTION変数がINSERTと一致しているかどうかを確認します。フィルタとして以下を指定します。
_IMAGE_TAG!=""_ACTION==INSERT
Pub/Sub トリガーのフィルタリング構文は、式の評価に Common Expression Language（CEL）を使用します。CEL の詳細については、cel-spec リポジトリをご覧ください。Pub/Sub トリガーに適用できるフィルタリングの構文のその他の例については、CEL を使用したビルドイベントのフィルタリングをご覧ください。
- [作成] をクリックしてビルドトリガーを作成します。 .
gcloud
gcloud コマンドを使用して、Artifact Registry の既存のイメージに push された新しいタグをリッスンするトリガーを作成するには:
- ターミナル ウィンドウを開きます。
gcloud alphaコマンドを実行して、プロジェクトにビルドトリガーを作成します。下の例では、置換変数（_IMAGE_TAG）で定義された指定ペイロードに基づいて、prodに一致するタグおよびINSERTに一致するアクションを持つビルドに応答するようにトリガーが構成されています。gcloud alpha builds triggers create pubsub \ --name=TRIGGER_NAME \ --topic=projects/PROJECT_ID/topics/TOPIC_NAME \ --build-config=BUILD_CONFIG \ # or --inline-config=INLINE_BUILD_CONFIG --substitutions=\ _IMAGE_TAG_='$(body.message.data.tag)' _ACTION='$(body.message.data.action)' --subscription-filter='_IMAGE_TAG == "" && _ACTION == "INSERT"' --repo=REPO_NAME --tag=TAG_NAME # or --branch=BRANCH_NAMEここで
- TRIGGER_NAME はトリガーの名前です。
- PROJECT_ID は Cloud プロジェクトの ID です。
- TOPIC_NAME は、登録した Pub/Sub トピックの名前です。
- BUILD_CONFIG は、ビルド構成ファイルへのパスです。
- INLINE_BUILD_CONFIG は、インライン ビルド構成ファイルへのパスです。
- REPO_NAME は、ビルドが呼び出されるソース リポジトリの名前です。
- TAG_NAME は、タグでビルドのトリガーを設定するタグの名前です。
- BRANCH_NAME は、ブランチでビルドのトリガーを設定する場合、ブランチの名前です。
Container Registry イベントに応答するビルドトリガーを作成する
イメージが push、タグ付け、削除された場合などの Container Registry イベントに応答する Pub/Sub トリガーを作成できます。このセクションでは、イメージがカスタム フィルタで設定したタグと一致する場合にビルドを呼び出す Pub/Sub トリガーを作成する方法について説明します。Container Registry について習熟されていない場合は、Container Registry のクイックスタートで、タグを使用してイメージを push および pull する方法を確認してください。
コンソール
Container Registry でイメージの push をリッスンし、Google Cloud Console を使用してタグ名に基づいて一致するトリガーを作成するには:
[トリガー] ページを開く
ページ上部でプロジェクトを選択し、[開く] をクリックします。
[トリガーを作成] をクリックします。
次のトリガー設定を入力します。
- 名前: トリガーの名前を入力します。
リージョン: トリガーのリージョンを選択します。
- リージョンとしてグローバルを選択した場合、Cloud Build はビルドを実行するためにデフォルトのプールを使用します。
- 非グローバル リージョンを選択して、トリガーに関連付けられたビルド構成ファイルでプライベート プールを指定すると、Cloud Build はプライベート プールを使用してビルドを実行します。この場合、トリガーで指定するリージョンは、プライベート プールを作成したリージョンと一致する必要があります。
- 非グローバル リージョンを選択し、トリガーに関連付けられたビルド構成ファイルでプライベート プールが指定されていない場合、Cloud Build はデフォルトのプールを使用してトリガーと同じリージョンでビルドを実行します。
説明（省略可）: トリガーの説明を入力します。
イベント: トリガーを起動するイベントとして [Pub/Sub メッセージ] を選択します。
サブスクリプション: トリガー イベントとして登録する Pub/Sub トピックを選択します。プロジェクトの既存のトピックがすべてプルダウン メニューに表示されます。
- Pub/Sub トピック: プルダウン メニューから
gcrトピックを選択するか、Pub/Sub 通知の構成の手順でトピックを手動で作成します。
- Pub/Sub トピック: プルダウン メニューから
ソース: ソースとして [第 1 世代] を選択します。
リポジトリ: 使用可能なリポジトリのリストから目的のリポジトリを選択します。
ブランチまたはタグ: ブランチまたはタグの値にマッチングさせる正規表現を指定します。有効な正規表現の構文については、RE2 構文をご覧ください。
コメント制御: イベントとして pull リクエスト（GitHub アプリのみ）を選択した場合は、ビルドをトリガーによって自動的に実行するかどうか、次のいずれかのオプションを選択します。
Required except for owners and collaborators: pull リクエストがリポジトリ所有者または共同編集者によって作成または更新されると、ビルドが自動的にトリガーによって実行されます。外部の投稿者がアクションを開始する場合、その pull リクエストで所有者または共同編集者が
/gcbrunにコメントした後にのみビルドが実行されます。必須: 投稿者を問わず pull リクエストが作成または更新されると、所有者または共同編集者が pull リクエストに
/gcbrunとコメントした後にのみビルドが実行されます。ビルドは、pull リクエストが変更されるたびに実行されます。不要: 投稿者を問わず pull リクエストが作成または更新されると、ビルドが自動的にトリガーで実行されます。
構成: ビルドに使用するリモート リポジトリにあるビルド構成ファイルを選択するか、インライン ビルド構成ファイルを作成します。
- タイプ: ビルドに使用する構成のタイプを選択します。
- Cloud Build 構成ファイル（yaml または json）: 構成にビルド構成ファイルを使用します。
- Dockerfile: 構成には
Dockerfileを使用します。 - Buildpacks: 構成には Buildpacks を使用します。
場所: 構成の場所を指定します。
- リポジトリ: 構成ファイルがリモート リポジトリにある場合は、ビルド構成ファイル、
Dockerfileディレクトリの場所、または Bullpack のディレクトリを指定します。ビルド構成タイプがDockerfileまたは buildpack の場合、ビルドするイメージの名前と、必要に応じてビルドのタイムアウトを指定する必要があります。Dockerfileまたは buildpack イメージ名を指定すると、ビルドが実行されるdocker buildまたはpackコマンドのプレビューが表示されます。 - buildpack の環境変数（省略可）: 構成タイプとして
buildpacksを選択した場合、[パック環境変数を追加] をクリックして buildpack 環境変数と値を指定します。buildpack 環境変数の詳細については、環境変数をご覧ください。 インライン: 構成オプションとして Cloud Build 構成ファイル（yaml または json）を選択した場合、インライン ビルド構成を指定できます。Google Cloud Console で [エディタを開く] をクリックして、YAML または JSON 構文でビルド構成ファイルを書き込みます。[完了] をクリックしてビルド構成ファイルを保存します。
- リポジトリ: 構成ファイルがリモート リポジトリにある場合は、ビルド構成ファイル、
- タイプ: ビルドに使用する構成のタイプを選択します。
代入変数（省略可）: ビルド構成のオプションとしてビルド構成ファイルを選択した場合、このフィールドを使用してトリガー固有の代入変数を定義できます。
次の例では、ペイロードからイメージタグの名前を取得し、さらに
gcrイベントに関連付けられたアクションを取得します。これを行うには、ペイロード バインディングを使用して置換変数を作成します。以下の変数と値を指定します。
変数の名前 変数の値 _IMAGE_TAG$(body.message.data.tag)_ACTION$(body.message.data.action)body.messageは、パブリッシャーによってパブリッシュされ、サブスクライバーによって使用される PubSubMessage を参照します。Pub/Sub 通知ペイロードに関するその他の例については、通知の例をご覧ください。フィルタ（省略可）: 置換変数にフィルタを指定することで、受信したペイロードに応じて、トリガーによってビルドを実行するかどうかを決定するフィルターをトリガー内に作成できます。ビルドを実行するには、フィルタ式が
trueに評価される必要があります。複数のメッセージがあるトピックで Pub/Sub トリガーを設定する場合は、フィルタリングを使用することをおすすめします。フィルタを使用すると、受信する Pub/Sub メッセージに応答して実行されるビルドをきめ細やかに制御できます。フィルタを使用しないトリガーの設定に関連するリスクについては、フィルタされていないトリガーに関連するリスクをご覧ください。
次の例では、
_IMAGE_TAGタグ変数の名前が特定のタグ名（prodなど）と一致する場合、トリガーがビルドを実行するようにします。フィルタ条件演算子を「==」として指定すると、完全一致が得られます。gcrイベントに関連付けられたアクションを確認することもできます。たとえば、新しく追加されたデータを探すには、_ACTIONをINSERTに指定します。フィルタとして以下を指定します。
_IMAGE_TAG==prod_ACTION==INSERT
Pub/Sub トリガーのフィルタリング構文は、式の評価に Common Expression Language（CEL）を使用します。CEL の詳細については、cel-spec リポジトリをご覧ください。Pub/Sub トリガーに適用できるフィルタリングの詳細な構文の例については、ビルドのフィルタリングをご覧ください。
- [作成] をクリックしてビルドトリガーを作成します。 .
gcloud
Container Registry でイメージの push をリッスンし、gcloud コマンドを使用してタグ名に基づいて一致するトリガーを作成するには:
- ターミナル ウィンドウを開きます。
gcloud alphaコマンドを実行して、プロジェクトにビルドトリガーを作成します。下の例では、置換変数（_IMAGE_TAG）で定義された指定ペイロードに基づいて、prodに一致するタグおよびINSERTに一致するアクションを持つビルドに応答するようにトリガーが構成されています。gcloud alpha builds triggers create pubsub \ --name=TRIGGER_NAME \ --topic=projects/PROJECT_ID/topics/TOPIC_NAME \ --build-config=BUILD_CONFIG \ # or --inline-config=INLINE_BUILD_CONFIG --substitutions=\ _IMAGE_TAG_='$(body.message.data.tag)' _ACTION='$(body.message.data.action)' --filter='_IMAGE_TAG == "prod" && _ACTION == "INSERT"' --repo=REPO_NAME --tag=TAG_NAME # or --branch=BRANCH_NAMEここで
- TRIGGER_NAME はトリガーの名前です。
- PROJECT_ID は Cloud プロジェクトの ID です。
- TOPIC_NAME は、登録した Pub/Sub トピックの名前です。
- BUILD_CONFIG は、ビルド構成ファイルへのパスです。
- INLINE_BUILD_CONFIG は、インライン ビルド構成ファイルへのパスです。
- REPO_NAME は、ビルドが呼び出されるソース リポジトリの名前です。
- TAG_NAME は、タグでビルドのトリガーを設定するタグの名前です。
- BRANCH_NAME は、ブランチでビルドのトリガーを設定する場合、ブランチの名前です。
Cloud Storage イベントに応答するビルドトリガーを作成する
新しいバイナリが既存のストレージ バケットに push された場合などの、Cloud Storage イベントに応答する Pub/Sub トリガーを作成できます。このセクションでは、アップロードされたバケットに新しいバイナリをデプロイする際にビルドに応答する Pub/Sub トリガーを作成する方法について説明します。Cloud Storage に習熟されていない場合は、クイックスタートをご覧ください。
コンソール
Google Cloud Console を使用して Cloud Storage イベントをリッスンするトリガーを作成するには、次のように操作します。
[トリガー] ページを開く
ページ上部でプロジェクトを選択し、[開く] をクリックします。
[トリガーを作成] をクリックします。
次のトリガー設定を入力します。
- 名前: トリガーの名前を入力します。
リージョン: トリガーのリージョンを選択します。
- リージョンとしてグローバルを選択した場合、Cloud Build はビルドを実行するためにデフォルトのプールを使用します。
- 非グローバル リージョンを選択して、トリガーに関連付けられたビルド構成ファイルでプライベート プールを指定すると、Cloud Build はプライベート プールを使用してビルドを実行します。この場合、トリガーで指定するリージョンは、プライベート プールを作成したリージョンと一致する必要があります。
- 非グローバル リージョンを選択し、トリガーに関連付けられたビルド構成ファイルでプライベート プールが指定されていない場合、Cloud Build はデフォルトのプールを使用してトリガーと同じリージョンでビルドを実行します。
説明（省略可）: トリガーの説明を入力します。
イベント: トリガーを起動するイベントとして [Pub/Sub メッセージ] を選択します。
サブスクリプション: トリガー イベントとして登録する Pub/Sub トピックを選択します。プロジェクトの既存のトピックがすべてプルダウン メニューに表示されます。
- Pub/Sub トピック: プルダウン メニューから
gcsトピックを選択するか、Cloud Storage の Pub/Sub 通知の手順でトピックを手動で作成します。
- Pub/Sub トピック: プルダウン メニューから
ソース: ソースとして [第 1 世代] を選択します。
リポジトリ: 使用可能なリポジトリのリストから目的のリポジトリを選択します。
ブランチまたはタグ: ブランチまたはタグの値にマッチングさせる正規表現を指定します。有効な正規表現の構文については、RE2 構文をご覧ください。
コメント制御: イベントとして pull リクエスト（GitHub アプリのみ）を選択した場合は、ビルドをトリガーによって自動的に実行するかどうか、次のいずれかのオプションを選択します。
Required except for owners and collaborators: pull リクエストがリポジトリ所有者または共同編集者によって作成または更新されると、ビルドが自動的にトリガーによって実行されます。外部の投稿者がアクションを開始する場合、その pull リクエストで所有者または共同編集者が
/gcbrunにコメントした後にのみビルドが実行されます。必須: 投稿者を問わず pull リクエストが作成または更新されると、所有者または共同編集者が pull リクエストに
/gcbrunとコメントした後にのみビルドが実行されます。ビルドは、pull リクエストが変更されるたびに実行されます。不要: 投稿者を問わず pull リクエストが作成または更新されると、ビルドが自動的にトリガーで実行されます。
構成: ビルドに使用するリモート リポジトリにあるビルド構成ファイルを選択するか、インライン ビルド構成ファイルを作成します。
- タイプ: ビルドに使用する構成のタイプを選択します。
- Cloud Build 構成ファイル（yaml または json）: 構成にビルド構成ファイルを使用します。
- Dockerfile: 構成には
Dockerfileを使用します。 - Buildpacks: 構成には Buildpacks を使用します。
場所: 構成の場所を指定します。
- リポジトリ: 構成ファイルがリモート リポジトリにある場合は、ビルド構成ファイル、
Dockerfileディレクトリの場所、または Bullpack のディレクトリを指定します。ビルド構成タイプがDockerfileまたは buildpack の場合、ビルドするイメージの名前と、必要に応じてビルドのタイムアウトを指定する必要があります。Dockerfileまたは buildpack イメージ名を指定すると、ビルドが実行されるdocker buildまたはpackコマンドのプレビューが表示されます。 - buildpack の環境変数（省略可）: 構成タイプとして
buildpacksを選択した場合、[パック環境変数を追加] をクリックして buildpack 環境変数と値を指定します。buildpack 環境変数の詳細については、環境変数をご覧ください。 インライン: 構成オプションとして Cloud Build 構成ファイル（yaml または json）を選択した場合、インライン ビルド構成を指定できます。Google Cloud Console で [エディタを開く] をクリックして、YAML または JSON 構文でビルド構成ファイルを書き込みます。[完了] をクリックしてビルド構成ファイルを保存します。
- リポジトリ: 構成ファイルがリモート リポジトリにある場合は、ビルド構成ファイル、
- タイプ: ビルドに使用する構成のタイプを選択します。
代入変数（省略可）: ビルド構成のオプションとしてビルド構成ファイルを選択した場合、このフィールドを使用してトリガー固有の代入変数を定義できます。
この例では、バケットにアップロードされた際の、新しいバイナリのデプロイを確認します。このデータを取得するには、ペイロード バインディングを使用して置換変数を作成します。
以下の変数と値を指定します。
変数の名前 変数の値 _EVENT_TYPE$(body.message.attributes.eventType)_BUCKET_ID$(body.message.attributes.bucketId)_OBJECT_ID$(body.message.attributes.objectId)body.messageは、パブリッシャーによってパブリッシュされ、サブスクライバーによって使用される PubSubMessage を参照します。Pub/Sub 通知ペイロードに関するその他の例については、通知の例をご覧ください。フィルタ（省略可）: 置換変数にフィルタを指定することで、受信したペイロードに応じて、トリガーによってビルドを実行するかどうかを決定するフィルターをトリガー内に作成できます。ビルドを実行するには、フィルタ式が
trueに評価される必要があります。複数のメッセージがあるトピックで Pub/Sub トリガーを設定する場合は、フィルタリングを使用することをおすすめします。フィルタを使用すると、受信する Pub/Sub メッセージに応答して実行されるビルドをきめ細やかに制御できます。フィルタを使用しないトリガーの設定に関連するリスクについては、フィルタされていないトリガーに関連するリスクをご覧ください。
新しいバイナリが特定のバケットにデプロイされている場合は、トリガーによってビルドが実行されるため、「==」演算子を使用して完全一致を確認できます。「一致」キーワードを使用して正規表現一致の対象にすることもできます。
フィルタとして以下を指定します。
_EVENT_TYPE==OBJECT_FINALIZE^<object-id>$に一致する_OBJECT_ID^<bucket-id>$に一致する_BUCKET_ID
- [作成] をクリックしてビルドトリガーを作成します。 .
gcloud
Cloud Storage で特定のイベントタイプを使用してビルドイベントをリッスンするビルドトリガーを作成するには:
- ターミナル ウィンドウを開きます。
gcloud alphaコマンドを実行して、プロジェクトにビルドトリガーを作成します。以下の例では、既存のストレージ バケットに push された新しいバイナリに関連付けられた Cloud Storage イベントでビルドに応答するように、トリガーが構成されています。gcloud alpha builds triggers create pubsub \ --name=TRIGGER_NAME \ --topic=projects/PROJECT_ID/topics/TOPIC_NAME \ --build-config=BUILD_CONFIG \ # or --inline-config=INLINE_BUILD_CONFIG --substitutions=\ _EVENT_TYPE='$(body.message.attributes.eventType)' _BUCKET_ID='$(body.message.attributes.bucketId)' _OBJECT_ID='$(body.message.attributes.objectId)' --filter='_EVENT_TYPE == "OBJECT_FINALIZE" && _OBJECT_ID.matches("<object-id>") && _BUCKET_ID.matches("<bucket-id>")' --repo=REPO_NAME --tag=TAG_NAME # or --branch=BRANCH_NAMEここで
- TRIGGER_NAME はトリガーの名前です。
- PROJECT_ID は Cloud プロジェクトの ID です。
- TOPIC_NAME は、登録した Pub/Sub トピックの名前です。
- BUILD_CONFIG は、ビルド構成ファイルへのパスです。
- INLINE_BUILD_CONFIG は、インライン ビルド構成ファイルへのパスです。
- REPO_NAME は、ビルドが呼び出されるソース リポジトリの名前です。
- TAG_NAME は、タグでビルドのトリガーを設定するタグの名前です。
- BRANCH_NAME は、ブランチでビルドのトリガーを設定する場合、ブランチの名前です。
フィルタされていないトリガーに関連するリスク
Pub/Sub トリガーにフィルタを構成していない場合、アーティファクトやオブジェクトがトリガーにより変更されると、新しいメッセージがリッスンするトピックに意図せずに公開され、トリガーが無限のビルドを呼び出す可能性があります。たとえば、次の場合にトリガーによって無限のビルドが呼び出される可能性があります。
gcrトピックを指定します。gcr内に任意のイメージまたはタグを作成します。- バケット内の特定のオブジェクトの
gcsトピックを指定し、そのオブジェクトを変更します。
無限ループが発生した場合、トリガーを削除するか、別のトピックを指定するように更新して、呼び出すビルドごとに追加料金が発生しないようにできます。
CEL を使用したビルドイベントのフィルタリング
Cloud Build は、ビルドリソースにリストされているフィールドの変数 build で CEL を使用して、トリガー ID、イメージリスト、置換変数などのビルドイベントと関連するフィールドにアクセスします。filter 文字列を使用すると、Build リソースに表示されているフィールドを使用してビルド構成ファイル内のビルドイベントをフィルタリングできます。フィールドに関連付けられた正確な構文を見つけるには、cloudbuild.proto ファイルをご覧ください。
トリガー ID によるフィルタリング
トリガー ID でフィルタリングするには、build.build_trigger_id を使用してトリガー ID の値をfilter フィールドに指定します。ここで、trigger-id は文字列であるトリガー ID です。
filter: build.build_trigger_id == trigger-id
ステータスによるフィルタリング
ステータスでフィルタリングするには、build.status を使用して、フィルタリングするビルドのステータスを filter フィールドに指定します。
次の例は、filter フィールドを使用して SUCCESS ステータスのビルドイベントをフィルタリングする方法を示しています。
filter: build.status == Build.Status.SUCCESS
さまざまなステータスのビルドをフィルタリングすることもできます。次の例は、filter フィールドを使用して、ステータスが SUCCESS、FAILURE、または TIMEOUT のビルドイベントをフィルタリングする方法を示しています。
filter: build.status in [Build.Status.SUCCESS, Build.Status.FAILURE, Build.Status.TIMEOUT]
フィルタリングできるその他のステータス値を確認するには、ビルドリソース リファレンスのステータスをご覧ください。
タグによるフィルタリング
タグでフィルタリングするには、build.tags を使用して filter フィールドにタグの値を指定します。ここで、tag-name はタグの名前です。
filter: tag-name in build.tags
size を使用すると、ビルドイベントで指定されたタグの数に基づいてフィルタリングできます。以下の例では、filter フィールドにより、1 つのタグが v1 に指定されたタグがちょうど 2 つあるビルドイベントがフィルタリングされます。
filter: size(build.tags) == 2 && "v1" in build.tags
イメージによるフィルタリング
イメージでフィルタリングするには、build.images を使用して filter フィールドにイメージの値を指定します。ここで image-name は、gcr.io/example/image-one などの Container Registry にリストされるイメージの完全な名前です。
filter: image-name in build.images
下の例では、filter がイメージ名として gcr.io/example/image-one または gcr.io/example/image-two が指定されているビルドイベントをフィルタリングします。
filter: "gcr.io/example/image-one" in build.images || "gcr.io/example/image-two" in build.images
時間によるフィルタリング
filter フィールドに build.create_time、build.start_time、build.finish_time のいずれかのオプションを指定すると、ビルドの作成時間、開始時間、終了時間に基づいてビルドイベントをフィルタリングできます。
下の例では、filter フィールドで timestamp を使用し、ビルドを作成するリクエスト時刻を 2020 年 7 月 20 日 午前 6 時に指定して、ビルドイベントをフィルタリングします。
filter: build.create_time == timestamp("2020-07-20:T06:00:00Z")
時刻の比較によりビルドイベントをフィルタリングすることもできます。下の例では、filter フィールドで timestamp を使用し、開始時刻を 2020 年 7 月 20 日午前 6 時と 2020 年 7 月 30 日午前 6 時の間に指定して、ビルドイベントをフィルタリングします。
filter: timestamp("2020-07-20:T06:00:00Z") >= build.start_time && build.start_time <= timestamp("2020-07-30:T06:00:00Z")
CEL での時間帯の表記方法に関する詳細については、時間帯の言語の定義をご覧ください。
ビルド時間でフィルタリングするには、duration を使用してタイムスタンプを比較します。下の例では、filter フィールドで duration を使用して、ビルドが 5 分以上実行されるビルドイベントをフィルタリングします。
filter: build.finish_time - build.start_time >= duration("5m")
置換によるフィルタリング
build.substitutions を使用して filter フィールドに置換変数を指定すると、置換によってフィルタリングできます。次の例では、filter フィールドは置換変数 substitution-variable を含むビルドを一覧表示し、substitution-variable が指定された substitution-value と一致するかどうかを確認します。
filter: build.substitutions[substitution-variable] == substitution-value
ここで
substitution-variableは置換変数の名前です。substitution-valueは、置換値の名前です。
また、デフォルトの置換変数値でフィルタリングすることもできます。次の例では、filter フィールドにブランチ名が master のビルドとリポジトリ名が github.com/user/my-example-repo のビルドが一覧表示されます。デフォルトの置換変数 BRANCH_NAME と REPO_NAME がキーとして build.substitutions に渡されます。
filter: build.substitutions["BRANCH_NAME"] == "master" && build.substitutions["REPO_NAME"] == "github.com/user/my-example-repo"
正規表現を使用して文字列をフィルタリングする場合は、組み込みの matches 関数を使用できます。以下の例では、filter フィールドは、ステータスが FAILURE または TIMEOUT であり、正規表現 v{DIGIT}.{DIGIT}.{3 DIGITS}) と一致する値を持つビルド置換変数 TAG_NAME のあるビルドでフィルタリングします。
filter: build.status in [Build.Status.FAILURE, Build.Status.TIMEOUT] && build.substitutions["TAG_NAME"].matches("^v\\d{1}\\.\\d{1}\\.\\d{3}$")`
デフォルトの置換値のリストについては、デフォルトの置換の使用をご覧ください。
次のステップ
gcloudコマンドまたは Cloud Build API を使用してビルドを手動で開始する方法を学習する。- トリガーを作成および管理する方法を学習する。
- ビルド結果を表示する方法を学習する。
- ビルドエラーをトラブルシューティングする方法について学習する。