はじめに
巷にはDangerというPull Requestのチェックを自動化するツールがありまして、自分のプロジェクトにも導入してみたいなと考えています。ただ、このDangerをCircleCI上で実行するにはちょっとした問題があるようです。
CircleCIでDangerを使おうとして困ったこと
どんなところで困るかというと、まずCircleCIは通常、PRをオープンしたタイミングでbuildを走らせるようにはなっていません。
この時点で「あっ…」となるのですが、丁寧に説明しますと
- コミットをGitHubにpushする
- →CIが走る
- →PRがまだないのでdangerは「PRがまだないよー」と終了してしまう
- →その後PRをオープンしても、PRをオープンしたタイミングではbuildは走らない
- →なので、もう一回GitHubにpushする or 手動でrebuildする必要がある（ここが面倒）
- →今度はPRオープン済みの状態なのでDangerが動作する
というわけです。
できればPRをオープンしたタイミングでCIが走ってDangerにPRを自動チェックしてほしいものです。
回避策がないか調べてみると、公式でオススメしている方法がCircleCIの設定で**‘Only build pull requests’を有効にする**というものでした。
# For setting up Circle CI, we recommend turning on "Only Build pull requests." in "Advanced Setting." Without this enabled,
# it is _really_ tricky for Danger to know whether you are in a pull request or not, as the environment metadata
# isn't reliable.
しかしこの設定を有効にするとCircleCIの挙動はどうなるの？という疑問があったので実際に有効化して試してみました。
実際に試してみた
まず、Only build pull requestsをOnにすると、PRが存在しない状態だとgithubにpushしただけではCIが走らなくります。
下記のような感じでNOT RUNとなりCIは実行されません。PRをオープンする前にテストを走らせたい派としてはPRをオープンしないとCIが走らなくなるという変更はけっこう不便だなと感じました。
次に先程pushしたブランチでPRをオープンしてみましょう。すると、今度はPRをオープンしたタイミングでCircleCIが走りました。Dangerも問題なくPRにコメントできています。
もちろん、PRをオープンした状態であれば、そのPRのブランチに追加でpushするたびにCIが走るようになります。
まとめ
- PRをオープンする前にCIを走らせる運用の場合は’Only build pull requests’だと都合が悪い。
- PRをオープンした後にCIを走らせても問題ないよという運用であれば’Only build pull requests’をOnにする対応で問題ない。
- 前者の運用を継続したい場合はWebHookを使ってLambdaか何かでWebAPI経由でCircleCIのbuildをキックするとかそんな感じでやるのが良いんでしょうか。近い内にやってみようと思います。