Pub/Sub イベントに応答してビルドを自動化する

第 1 世代 第 2 世代

Cloud Build Pub/Sub トリガーを使用すると、Pub/Sub で公開された Google Cloud イベントに応答してビルドを実行できます。Pub/Sub イベントの情報を使用してビルドをパラメータ化し、イベントに応答してビルドを実行するかどうかを決定できます。Pub/Sub トリガーは、任意の Pub/Sub トピックをリッスンするように構成できます。

このページでは、Artifact Registry、Container Registry（非推奨）、および Cloud Storage 上のイベントに応じてビルドを自動化する Pub/Sub トリガーを作成する方法について説明します。

注: Pub/Sub トリガーは、Cloud Build に関連付けられたトリガータイプです。Google Cloud 内の追加のコンテキストで使用される Pub/Sub トリガーは、明示的に記述されていない限り、Cloud Build Pub/Sub トリガーを参照しない可能性があります。

制限事項

VPC Service Controls が使用されている場合、Cloud Build Pub/Sub トリガーはサポートされません。

始める前に

• Cloud Build API を有効にします。

  API を有効にする

• ソースコードにリポジトリ内のビルド構成ファイルまたは Dockerfile が含まれていることを確認します。

• このページで gcloud コマンドを使用するには、Google Cloud CLI をインストールします。

  注: すでに gcloud CLI をインストールしている場合は、gcloud components update を実行して、最新のバージョンがインストールされていることを確認してください。

Artifact Registry イベントに応答するビルドトリガーを作成する

イメージが push、タグ付け、削除された場合などの Artifact Registry イベントに応答する Pub/Sub トリガーを作成できます。このセクションでは、新しいタグが既存のイメージに push されたときにビルドを起動する Pub/Sub トリガーを作成する方法について説明します。Artifact Registry に習熟されていない場合は、Artifact Registry の概要をご覧ください。

注: Pub/Sub トリガーで Cloud Build のネイティブ インテグレーションを使用して、GitHub Enterprise、Bitbucket データセンター、Bitbucket Server のリポジトリをビルドすることはできません。外部のソースコード管理システムによってリポジトリのクローンを作成し、ビルドするには、ビルドトリガーの作成と管理を参照して、インラインでビルド構成を指定する方法を確認してください。

コンソール

Google Cloud Console を使用して、Artifact Registry の既存のイメージに push された新しいタグをリッスンするトリガーを作成するには、次のとおり操作します。

1. [トリガー] ページを開く

   [トリガー] ページを開く

2. ページ上部でプロジェクトを選択し、[開く] をクリックします。

3. [トリガーを作成] をクリックします。

4. 次のトリガー設定を入力します。

   • 名前: トリガーの名前を入力します。

   • リージョン: トリガーのリージョンを選択します。

     • トリガーに関連付けられたビルド構成ファイルでプライベート プールが指定されている場合、Cloud Build は、そのプライベート プールを使用してビルドを実行します。この場合、トリガーで指定するリージョンは、プライベート プールを作成したリージョンと一致する必要があります。
     • トリガーに関連付けられたビルド構成ファイルでプライベート プールが指定されていない場合、Cloud Build はデフォルトのプールを使用してトリガーと同じリージョンでビルドを実行します。

   • 説明（省略可）: トリガーの説明を入力します。

   • イベント: トリガーを起動するイベントとして [Pub/Sub メッセージ] を選択します。

   • サブスクリプション: トリガー イベントとして登録する Pub/Sub トピックを選択します。プロジェクトの既存のトピックがすべてプルダウン メニューに表示されます。

     • Pub/Sub トピック: プルダウン メニューから gcr トピックを選択するか、Pub/Sub 通知の構成の手順でトピックを手動で作成します。
     注: トリガーを作成すると、トリガーのサブスクリプションが自動的に作成されます。[Pub/Sub サブスクリプション] ページでサブスクリプションを確認できます。

   • ソース: Pub/Sub トリガーの実行時にビルドするソースを選択します。ソースとして第 1 世代または第 2 世代を指定できます。

     注: リポジトリのリージョンは、トリガーのリージョンと一致する必要があります。

     • リポジトリ: 使用可能なリポジトリのリストから目的のリポジトリを選択します。

     • ブランチまたはタグ: ブランチまたはタグの値にマッチングさせる正規表現を指定します。有効な正規表現の構文については、RE2 構文をご覧ください。

     • コメント制御: イベントとして pull リクエスト（GitHub アプリのみ）を選択した場合は、ビルドをトリガーによって自動的に実行するかどうか、次のいずれかのオプションを選択します。

       警告: リポジトリへの読み取りアクセス権を持つすべてのユーザーが pull リクエストを送信できます。これにより、pull リクエスト内のソースコードの変更を含むビルドが実行される可能性が生じます。この動作を無効にするには、公開リポジトリで pull リクエストを行うときに、手動承認を使用してビルドを制御することをおすすめします。トリガーのビルド時権限の詳細については、ビルドトリガーと Cloud Build サービス アカウントをご覧ください。

       • 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 構文でビルド構成ファイルを書き込みます。[完了] をクリックしてビルド構成ファイルを保存します。

         注: Dockerfile または Buildpacks では、インライン ビルド構成はサポートされていません。

   • 代入変数（省略可）: ビルド構成のオプションとしてビルド構成ファイルを選択した場合、このフィールドを使用してトリガー固有の代入変数を定義できます。

     次の例では、ペイロードからイメージタグの名前を取得し、さらに gcr イベントに関連付けられたアクションを取得します。これを行うには、ペイロード バインディングを使用して置換変数を作成します。

     以下の変数と値を指定します。

     変数の名前	変数の値
     _IMAGE_TAG	$(body.message.data.tag)
     _ACTION	$(body.message.data.action)

     body.message は、パブリッシャーによってパブリッシュされ、サブスクライバーによって使用される PubSubMessage を参照します。Pub/Sub 通知ペイロードに関するその他の例については、通知の例をご覧ください。

     注: 代入変数の定義は任意ですが、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 リポジトリをご覧ください。

5. [作成] をクリックしてビルドトリガーを作成します。

gcloud

gcloud コマンドを使用して、Artifact Registry の既存のイメージに push された新しいタグをリッスンするトリガーを作成するには:

1. ターミナル ウィンドウを開きます。

2. gcloud コマンドを実行して、プロジェクトにビルドトリガーを作成します。下の例では、置換変数（_IMAGE_TAG）で定義された指定ペイロードに基づいて、prod に一致するタグおよび INSERT に一致するアクションを持つビルドに応答するようにトリガーが構成されています。

    gcloud builds triggers create pubsub \
      --region=REGION \
      --name=TRIGGER_NAME \
      --repository=projects/PROJECT_ID/locations/REGION/connections/CONNECTION_NAME/repositories/REPO_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"' \
      --tag=TAG_NAME  # or --branch=BRANCH_NAME
   

ここで

• REGION はトリガーのリージョンです。
• TRIGGER_NAME はトリガーの名前です。
• PROJECT_ID は Cloud プロジェクトの ID です。
• CONNECTION_NAME は、ホスト接続の名前です。
• REPO_NAME はリポジトリの名前です。
• TOPIC_NAME は、登録した Pub/Sub トピックの名前です。
• BUILD_CONFIG は、ビルド構成ファイルへのパスです。
• INLINE_BUILD_CONFIG は、インライン ビルド構成ファイルへのパスです。
• TAG_NAME は、タグでビルドのトリガーを設定するタグの名前です。
• BRANCH_NAME は、ブランチでビルドのトリガーを設定する場合、ブランチの名前です。

Container Registry イベントに応答するビルドトリガーを作成する

注: Container Registry は非推奨で、提供終了となります。2024 年 1 月 8 日より前に Container Registry を使用していない組織では、デフォルトで Artifact Registry に新しい gcr.io リポジトリがホストされます。2024 年 5 月 15 日以降、それまで Container Registry を使用していなかった Google Cloud プロジェクトでは、Artifact Registry で gcr.io ドメインのイメージのホスティングと管理のみがサポートされます。

Container Registry は 2025 年 3 月 18 日に提供終了となる予定です。サポート終了の詳細については、Container Registry のサポート終了をご覧ください。

イメージが push、タグ付け、削除された場合などの Container Registry イベントに応答する Pub/Sub トリガーを作成できます。このセクションでは、イメージがカスタム フィルタで設定したタグと一致する場合にビルドを呼び出す Pub/Sub トリガーを作成する方法について説明します。Container Registry について習熟されていない場合は、Container Registry のクイックスタートで、タグを使用してイメージを push および pull する方法を確認してください。

コンソール

Container Registry でイメージの push をリッスンし、Google Cloud Console を使用してタグ名に基づいて一致するトリガーを作成するには:

1. [トリガー] ページを開く

   [トリガー] ページを開く

2. ページ上部でプロジェクトを選択し、[開く] をクリックします。

3. [トリガーを作成] をクリックします。

4. 次のトリガー設定を入力します。

   • 名前: トリガーの名前を入力します。

   • リージョン: トリガーのリージョンを選択します。

     • トリガーに関連付けられたビルド構成ファイルでプライベート プールが指定されている場合、Cloud Build は、そのプライベート プールを使用してビルドを実行します。この場合、トリガーで指定するリージョンは、プライベート プールを作成したリージョンと一致する必要があります。
     • トリガーに関連付けられたビルド構成ファイルでプライベート プールが指定されていない場合、Cloud Build はデフォルトのプールを使用してトリガーと同じリージョンでビルドを実行します。

   • 説明（省略可）: トリガーの説明を入力します。

   • イベント: トリガーを起動するイベントとして [Pub/Sub メッセージ] を選択します。

   • サブスクリプション: トリガー イベントとして登録する Pub/Sub トピックを選択します。プロジェクトの既存のトピックがすべてプルダウン メニューに表示されます。

     • Pub/Sub トピック: プルダウン メニューから gcr トピックを選択するか、Pub/Sub 通知の構成の手順でトピックを手動で作成します。
     注: トリガーを作成すると、トリガーのサブスクリプションが自動的に作成されます。[Pub/Sub サブスクリプション] ページでサブスクリプションを確認できます。

   • ソース: Pub/Sub トリガーの実行時にビルドするソースを選択します。ソースとして第 1 世代または第 2 世代を指定できます。

     注: リポジトリのリージョンは、トリガーのリージョンと一致する必要があります。

     • リポジトリ: 使用可能なリポジトリのリストから目的のリポジトリを選択します。

     • ブランチまたはタグ: ブランチまたはタグの値にマッチングさせる正規表現を指定します。有効な正規表現の構文については、RE2 構文をご覧ください。

     • コメント制御: イベントとして pull リクエスト（GitHub アプリのみ）を選択した場合は、ビルドをトリガーによって自動的に実行するかどうか、次のいずれかのオプションを選択します。

       警告: リポジトリへの読み取りアクセス権を持つすべてのユーザーが pull リクエストを送信できます。これにより、pull リクエスト内のソースコードの変更を含むビルドが実行される可能性が生じます。この動作を無効にするには、公開リポジトリで pull リクエストを行うときに、手動承認を使用してビルドを制御することをおすすめします。トリガーのビルド時権限の詳細については、ビルドトリガーと Cloud Build サービス アカウントをご覧ください。

       • 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 構文でビルド構成ファイルを書き込みます。[完了] をクリックしてビルド構成ファイルを保存します。

         注: Dockerfile または Buildpacks では、インライン ビルド構成はサポートされていません。

   • 代入変数（省略可）: ビルド構成のオプションとしてビルド構成ファイルを選択した場合、このフィールドを使用してトリガー固有の代入変数を定義できます。

     次の例では、ペイロードからイメージタグの名前を取得し、さらに gcr イベントに関連付けられたアクションを取得します。これを行うには、ペイロード バインディングを使用して置換変数を作成します。

     以下の変数と値を指定します。

     変数の名前	変数の値
     _IMAGE_TAG	$(body.message.data.tag)
     _ACTION	$(body.message.data.action)

     body.message は、パブリッシャーによってパブリッシュされ、サブスクライバーによって使用される PubSubMessage を参照します。Pub/Sub 通知ペイロードに関するその他の例については、通知の例をご覧ください。

     注: 代入変数の定義は任意ですが、Pub/Sub メッセージにカスタム フィルタリングを設定する場合は、代入変数が必要になります（詳細については、以下のフィルタをご覧ください）。

   • フィルタ（省略可）: 置換変数にフィルタを指定することで、受信したペイロードに応じて、トリガーによってビルドを実行するかどうかを決定するフィルターをトリガー内に作成できます。ビルドを実行するには、フィルタ式が true に評価される必要があります。

     複数のメッセージがあるトピックで Pub/Sub トリガーを設定する場合は、フィルタリングを使用することをおすすめします。フィルタを使用すると、受信する Pub/Sub メッセージに応答して実行されるビルドをきめ細やかに制御できます。フィルタを使用しないトリガーの設定に関連するリスクについては、フィルタされていないトリガーに関連するリスクをご覧ください。

     次の例では、_IMAGE_TAG タグ変数の名前が特定のタグ名（prod など）と一致する場合、トリガーがビルドを実行するようにします。フィルタ条件演算子を「==」として指定すると、完全一致が得られます。gcr イベントに関連付けられたアクションを確認することもできます。たとえば、新しく追加されたデータを探すには、_ACTION を INSERT に指定します。

     フィルタとして以下を指定します。

     • _IMAGE_TAG.matches(prod)
     • _ACTION.matches(INSERT)
     注: ブール演算子 &&（および）と ||（または）を指定して条件をネストすることもできます。!（否定）記号はサポートされていません。

     Pub/Sub トリガーのフィルタリング構文は、式の評価に Common Expression Language（CEL）を使用します。CEL の詳細については、cel-spec リポジトリをご覧ください。Pub/Sub トリガーに適用できるフィルタリングの詳細な構文の例については、ビルドのフィルタリングをご覧ください。

5. [作成] をクリックしてビルドトリガーを作成します。

gcloud

Cloud Storage イベントに応答するビルドトリガーを作成する

新しいバイナリが既存のストレージ バケットに push された場合などの、Cloud Storage イベントに応答する Pub/Sub トリガーを作成できます。このセクションでは、アップロードされたバケットに新しいバイナリをデプロイする際にビルドに応答する Pub/Sub トリガーを作成する方法について説明します。Cloud Storage に習熟されていない場合は、クイックスタートをご覧ください。

コンソール

Google Cloud Console を使用して Cloud Storage イベントをリッスンするトリガーを作成するには、次のように操作します。

1. [トリガー] ページを開く

   [トリガー] ページを開く

2. ページ上部でプロジェクトを選択し、[開く] をクリックします。

3. [トリガーを作成] をクリックします。

4. 次のトリガー設定を入力します。

   • 名前: トリガーの名前を入力します。

   • リージョン: トリガーのリージョンを選択します。

     • トリガーに関連付けられたビルド構成ファイルでプライベート プールが指定されている場合、Cloud Build は、そのプライベート プールを使用してビルドを実行します。この場合、トリガーで指定するリージョンは、プライベート プールを作成したリージョンと一致する必要があります。
     • トリガーに関連付けられたビルド構成ファイルでプライベート プールが指定されていない場合、Cloud Build はデフォルトのプールを使用してトリガーと同じリージョンでビルドを実行します。

   • 説明（省略可）: トリガーの説明を入力します。

   • イベント: トリガーを起動するイベントとして [Pub/Sub メッセージ] を選択します。

   • サブスクリプション: トリガー イベントとして登録する Pub/Sub トピックを選択します。プロジェクトの既存のトピックがすべてプルダウン メニューに表示されます。

     • Pub/Sub トピック: プルダウン メニューから gcs トピックを選択するか、Cloud Storage の Pub/Sub 通知の構成の手順を使用して、トピックを手動で作成します。
     注: トリガーを作成すると、トリガーのサブスクリプションが自動的に作成されます。[Pub/Sub サブスクリプション] ページでサブスクリプションを確認できます。

   • ソース: Pub/Sub トリガーの実行時にビルドするソースを選択します。ソースとして第 1 世代または第 2 世代を指定できます。

     注: リポジトリのリージョンは、トリガーのリージョンと一致する必要があります。

     • リポジトリ: 使用可能なリポジトリのリストから目的のリポジトリを選択します。

     • ブランチまたはタグ: ブランチまたはタグの値にマッチングさせる正規表現を指定します。有効な正規表現の構文については、RE2 構文をご覧ください。

     • コメント制御: イベントとして pull リクエスト（GitHub アプリのみ）を選択した場合は、ビルドをトリガーによって自動的に実行するかどうか、次のいずれかのオプションを選択します。

       警告: リポジトリへの読み取りアクセス権を持つすべてのユーザーが pull リクエストを送信できます。これにより、pull リクエスト内のソースコードの変更を含むビルドが実行される可能性が生じます。この動作を無効にするには、公開リポジトリで pull リクエストを行うときに、手動承認を使用してビルドを制御することをおすすめします。トリガーのビルド時権限の詳細については、ビルドトリガーと Cloud Build サービス アカウントをご覧ください。

       • 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 構文でビルド構成ファイルを書き込みます。[完了] をクリックしてビルド構成ファイルを保存します。

         注: Dockerfile または Buildpacks では、インライン ビルド構成はサポートされていません。

   • 代入変数（省略可）: ビルド構成のオプションとしてビルド構成ファイルを選択した場合、このフィールドを使用してトリガー固有の代入変数を定義できます。

     この例では、バケットにアップロードされた際の、新しいバイナリのデプロイを確認します。このデータを取得するには、ペイロード バインディングを使用して置換変数を作成します。

     以下の変数と値を指定します。

     変数の名前	変数の値
     _EVENT_TYPE	$(body.message.attributes.eventType)
     _BUCKET_ID	$(body.message.attributes.bucketId)
     _OBJECT_ID	$(body.message.attributes.objectId)

     body.message は、パブリッシャーによってパブリッシュされ、サブスクライバーによって使用される PubSubMessage を参照します。Pub/Sub 通知ペイロードに関するその他の例については、通知の例をご覧ください。

     注: 代入変数の定義は任意ですが、Pub/Sub メッセージにカスタム フィルタリングを設定する場合は、代入変数が必要になります（詳細については、以下のフィルタをご覧ください）。

   • フィルタ（省略可）: 置換変数にフィルタを指定することで、受信したペイロードに応じて、トリガーによってビルドを実行するかどうかを決定するフィルターをトリガー内に作成できます。ビルドを実行するには、フィルタ式が true に評価される必要があります。

     複数のメッセージがあるトピックで Pub/Sub トリガーを設定する場合は、フィルタリングを使用することをおすすめします。フィルタを使用すると、受信する Pub/Sub メッセージに応答して実行されるビルドをきめ細やかに制御できます。フィルタを使用しないトリガーの設定に関連するリスクについては、フィルタされていないトリガーに関連するリスクをご覧ください。

     新しいバイナリが特定のバケットにデプロイされている場合は、トリガーによってビルドが実行されるため、「==」演算子を使用して完全一致を確認できます。「一致」キーワードを使用して正規表現一致の対象にすることもできます。

     フィルタとして以下を指定します。

     • _EVENT_TYPE == OBJECT_FINALIZE
     • ^<object-id>$ に一致する _OBJECT_ID
     • ^<bucket-id>$ に一致する _BUCKET_ID

5. [作成] をクリックしてビルドトリガーを作成します。
.

gcloud

フィルタされていないトリガーに関連するリスク

Pub/Sub トリガーにフィルタを構成していない場合、アーティファクトやオブジェクトがトリガーにより変更されると、新しいメッセージがリッスンするトピックに意図せずに公開され、トリガーが無限のビルドを呼び出す可能性があります。たとえば、次の場合にトリガーによって無限のビルドが呼び出される可能性があります。

• gcr トピックを指定します。
• gcr 内に任意のイメージまたはタグを作成します。
• バケット内の特定のオブジェクトの gcs トピックを指定し、そのオブジェクトを変更します。

無限ループが発生した場合、トリガーを削除するか、別のトピックを指定するように更新して、呼び出すビルドごとに追加料金が発生しないようにできます。

次のステップ

• gcloud コマンドまたは Cloud Build API を使用してビルドを手動で開始する方法を学習する。
• トリガーを作成および管理する方法を学習する。
• ビルド結果を表示する方法を学習する。
• ビルドエラーをトラブルシューティングする方法について学習する。