Firebase HostingのデプロイをWebhook(API)経由で行う
前回の記事でCloud BuildでFirebase Hostingのデプロイを行うようにした。
今回はCloud BuildのトリガーにWebhookを設定して、Webhook（API）経由でFirebase Hostingへのデプロイが行えるようにする。
トリガーの設定は公式ドキュメントに沿って進めていく。
なお、Webhookトリガーはまだプレビュー版となっており、今後手順が変わる可能性もあるので注意。
事前対応
- Cloud Build and Secret Manager API を有効にする
- 認証情報ページでAPIキーを作成
- APIの制限で「Cloud Build API」のみ有効にした
Cloud Buildでの対応
- トリガー => トリガーを作成
- イベントの「Webhookイベント」にチェック
- シークレットを新規作成
- Webhook URLのプレビューに記載されているURLをメモしておく
https://cloudbuild.googleapis.com/v1/projects/<project_id>/triggers/<trigger_name>:webhook?secret=<SECRET_KEY>&key=<API_KEY>- 構成 => 形式 => Cloud Build 構成ファイル（yaml または json）
Webhook経由でデプロイを実行
Webhook URLに対しPOSTリクエストを投げるとCloud Buildが実行される。
curlだと↓のようになる。
curl -v -XPOST -d '{}' -H 'Content-Type: application/json' 'https://cloudbuild.googleapis.com/v1/projects/<project_id>/triggers/<trigger_name>:webhook?secret=<SECRET_KEY>&key=<API_KEY>'これでWebhook（API）経由でFirebase Hostingへのデプロイが行えるようになった。
最終的にはこのAPIをCloud Function等で呼び出せるようにして、サイト上に設置したデプロイボタンをトリガーにデプロイできるようにした。
Webhook経由でのデプロイはなかなか便利。
補足
Github Actionsでも workflow_dispatch を使うと同じようなことはできそうだが、API呼び出しの際にPersonal Access Tokenを付与する必要がある。
Personal Access Tokenの場合、全リポジトリに対する権限しか設定できないため権限が強すぎると判断して今回はCloud Buildを利用した。
Cloud Buildの場合は↓となっており、Github ActionsのWebhookよりも厳密な権限管理ができる。
- Webhook呼び出しの際にはプロジェクト専用に作成したAPIキーとシークレットを利用している
- Build時に使用するGitHubのトークンについてはCloud Build GitHubアプリに対して許可したリポジトリのみが対象となっている