はじめに

GitLab.comにプッシュした後は、ビルドが無事完了したのを見届けて(たまにデプロイが失敗していることがある)からページも更新されているかチェックしたくなるのが人ってもの。ローカルでちゃんと動いていることを確認していたとしてもだ。

でも、最近のGitLabはビルド行列が長くなってきて、完了はおろか開始するまでも待ちきれないくらい時間がかかる。そこでIFTTTを使ってビルドステータスをiPhoneにプッシュ通知させようというのがこのページの趣旨。

GitlabとIFTTTは直接連携できないのだか、GitLabにはWebhookを送信できる機能がありIFTTTにもWebhookwo受信出来る機能がある。
なのでWebhookをやり取りして、ビルドステータスチェンジのタイミングをトリガーにできるのだが、お互い期待しているデータ構造が違うためIFTTTは反応してくれない。

そこで、間にZapierというサービスを挟んでGitLabとIFTTTの違いを吸収させて、最終的にIFTTTでiPhoneへプッシュ通知させてみた。

gitlab webhook

概要

はじめにでも書いたが、流れ的には以下の感じになる。

GitLabにGitでプッシュ
   ↓
ビルドステータスが変わったタイミングでGitLabがzapierへWebhook送信
   ↓
Webhookを受け取ったZapierが受信したJSONの一部を拾ってIFTTTへWebhook送信
   ↓
Webhookを受け取ったIFTTTが連携済みのiPhoneへプッシュ通知

各サービスにアカウントがあれば見た目ほど面倒ではないが、アカウントを取りながらだと少し面倒かもしれない。

ここではGitLabとiPhoneで説明をしているが、GitHubもしくはWebhookを投げれるサービスだったらなんでもステータスを受け取れると思う。そうそれもAndroidでもね。

設定方法

設定はWebhook送信先のURLを作りながら進めるのでWebhookの送信順と設定の進みが違ってちょっと分かりづらいし、詰まるとどこで失敗してるかわからなくなる。
そんなときは次項の「デバッグ時の便利ツール」で紹介しているサービスでデータの確認をしながら進めると分かりやすい。

IFTTT

IFTTTはレシピを共有できる機能があるので、以下のレシピに適当な名前(後で使うのでスペース無しのアルファベットにしておいたほうが良いと思う)をつけて取り込むだけで良いと思う。

IFTTTのWebhook送信URLはMaker Channelにある「How to Trigger Events」というリンク先で確認できる。また、このページでURLのインプットボックスに先ほど作ったレシピの名前を入力し、 Value1 欄に success と入力して「Test It」ボタンをクリックするとうまく行けば下記のバーナーが出てiPhoneへ通知が飛ぶ。

ifttt maker trigger

通知が来ない場合はiPhoneとの連携がうまくできてないかレシピ名が間違っていると思われる。

GitLab

GitLabはこの頃UIの変化が毎月のようにあるのでスクリーンショットを貼りづらいが、

プロジェクトの設定から「Webhooks」を選択
URLにはZapierの送信先を指定
Triggerは「Build events」だけ指定
「Add Webhook」ボタンをクリック

するだけで完了。

gitlab webhook

Zapierの送信先が必要になるので、次項のZapierの設定と同時に進める必要がある。

Zapier

Zapierの方はレシピの共有という機能はないのでいちから設定することになるのだが、内容としてはWebhookを受け取ってWebhookを送信するっていうイメージ。

流れに沿ってやればそれほど難しくは無いはず。

なんだけど、途中の「Test this Step」というところでは実際にGitLabからビルドトリガーのWebhookを実際に送る必要があるので、そこだけ注意が欲しい。そこで実際のWebhookを送ると、下記のように次のステップで送られた内容からデータを操作することができるようになる。

zapier webhook

Data欄でStep1の Build Status が選べるようになっていれば、Keyを value1にしてValueに Build Status を選べば他に躓くところは無いと思われる。

ここまで出来たらActionの「Test this Step」でテストを行ってiPhoneに通知が届けばお疲れ様でしたということになる。

デバッグ時の便利ツール

Webhookはとにかくデバッグしにくくて、宛先ホストに届いているのか？どんなデータが届いているのか？そもそもキック自体されているのか？といったところが非常につかみにくいのだが、調べているうちに良いサービスを見つけた。

RequestBin http://requestb.in/

Inspect HTTP Requests

RequestBin gives you a URL that will collect requests made to it and let you inspect them in a human-friendly way. Use RequestBin to see what your HTTP client is sending or to inspect and debug webhook requests.

たんにアクセスがあったときのデータを保存して表示してくれるサービスなのだが、アカウントを作る必要もなく自動的に48時間でデータも消えるので気分的にも安心。

まとめ

この仕組を作ってたりこの文章を書いているうちにGitLabのbuild行列も治まってきたのか、それほど遅延はなくなってきている。

それでも、ステータスチェンジが通知されるっていうのは想像以上に安心だし、これからいろいろな処理が重なって時間がかかっていく一方だと思うと、我ながら良い仕組みだと思う。

本音を言えばZapierのZapは5つでTaskが100回/月という制限がちょっと厳しい。例えば一回ビルドが走ると pending → running → success と3回Taskが走るので、単純計算だと毎日一度しかプッシュできないことになる。

なので、Webhookを受け取ってJSでちょちょっと処理を入れられてその結果をWebhookで送信できるというサービスがあるとうれしい。だれか作ってください。