CircleCI のInbound Webhook を使ってパイプラインをトリガーしてみた

## はじめに
CircleCI でカスタマーサクセスをしている鈴木です。今年読んだ短編小説では笹原千波さんの『風になるにはまだ』がとても良かったです。

本記事では 11/18 に Open Preview として提供が開始された CircleCI の [Inbound Webhook](https://discuss.circleci.com/t/trigger-pipelines-from-anywhere-inbound-webhooks-now-in-preview/49864) という機能を紹介します。

はじめにお伝えしますと、「今後が楽しみな機能」です。と言うのも、すぐに使えるユーザーが限られているからです。現在この機能を利用できるのは2023年9月以降に [GitHub App 経由で CircleCI と連携](https://discuss.circleci.com/t/circleci/49061)した GitHub Organization です。残念ながら、2023年9月よりも前から CircleCI をご利用いただいている場合は利用できません。もしご興味いただけたら、まだ CircleCI と連携していない GitHub Organization でお試しください。
そして、この Inbound Webhook の機能そのものにもまだまだ改善の余地がありそうです。

## Inbound Webhook とは
CircleCI のワークフローやジョブの情報を Webhook で外部のサービスに送信する機能は以前からありました。CircleCI から外部のサービスに出ていく通信なので Outbound Webhook と言えるでしょう。
Inbound Webhook は、外部サービスから CircleCI へ飛び込んでくる Webhook を指しています。その Inbound Webhook をきっかけにパイプラインをトリガーします。パイプラインをトリガーする方法が増えることで色々と便利な利用ができそうです。

## 活用例
Open Preview を開始したタイミングで [CircleCI が公開したブログ記事](https://circleci.com/blog/mlops-trigger-inbound-webhooks/)では Hugging Face で新しいバージョンのモデルが公開されるたびに Webhook を受け取って、モデルの評価を行うパイプラインをトリガーする例を解説しています。

他にも以下のようなイベントでパイプラインをトリガーすることができそうです。
- GitHub での各種イベント
- Jira のようなチケット管理システムでのイベント
- Synk のようなセキュリティ関連ツールからのアラート
- PagerDuty のようなインシデント管理サービスからのアラート
- Docker Hub のようなレジストリサービス上のコンテンツ更新

## 設定方法
CircleCI と連携している各プロジェクトの Project Settings にある Triggers を開きます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/11243/138c64a1-a7de-37ad-d0d8-f4a61c4f7f58.png)

すでに GitHub App Trigger という Trigger が存在している場合、GitHub Apps 経由で CircleCI との連携を行っていて、Inbound Webhook の設定が可能です。もし、GitHub App Trigger が存在しない場合、Add Trigger で設定できるのは Scheduled Pipeline （パイプラインのスケジュール実行）です。

青い Add Trigger ボタンを押すと Trigger の種類を選択するプルダウンメニューが表示されます。Inbound Webhook を選んだ状態で Next に進みます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/11243/a4782940-e31d-6db8-617e-e68e846f3840.png)

次に Trigger の名前と説明文を入力します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/11243/561dcea9-4ca3-6e6f-67e4-7e5f4cb7e3fc.png)

上の画面で名前と説明文を入力して Save すると外部サービスに登録するシークレットと、そのシークレットを含む Webhook URL が表示されます。
この画面でコピーしておかないと二度と現れません。コピーし忘れたら作り直しましょう。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/11243/60198848-b0fa-1c3a-ab50-6c2c9bf3bf56.png)


コピーを終えたら Done ボタンを押して登録完了です。
この例では Jira でチケットを起票したタイミングで CircleCI に Webhook を送信するように Jira 側の管理画面で設定しました。ここでは詳細を省きます。

CircleCI と Jira、両方の設定を終えて、チケットを起票するとパイプラインが実行されました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/11243/3aed65ba-0bba-ff32-20ac-51bab0a9aeea.png)



CircleCI では config.yml という設定ファイルによってビルドからデリバリープロセスまでを集中管理しています。その config.yml に「ポリシー（config.yml の記述ルール）」を設けて、自社の管理下にあるプロジェクトの config.yml がそのポリシーから逸脱している場合にアラートを出したり、ビルドを中止する機能です。


## 課題
というわけで簡単に機能を紹介しましたが、機能改善の余地があり、伸びしろがいっぱいです。
改善が必要だなと感じている点をざっと上げてみます。
- 既存の多くの CircleCI ユーザーが使えるようにする。（現時点では、2023年9月以降に GitHub App 経由で CircleCI と連携した GitHub Organization のみが使える。）
- Inbound Webhook 用のパイプラインをトリガーする。さらに発展して、外部サービスの Webhook の Payload の内容に応じてパイプラインを制御する。（現時点では、単にCircleCIのパイプラインをトリガーするのみ。Pipeline パラメータの活用などもできない。）
- 代表的なサービスは簡単なセットアップができるように UI を工夫する。


## おわりに
というわけで CircleCI の Inbound Webhook という機能を見てみました。現時点では限定的な利用にとどまりますが、カスタマイズできる内容が増えて、Webhook を飛ばせるサービスであればどんなものでも CircleCI との連携対象になるのあれば活用の幅が広い、便利な機能となりそうで楽しみです。