travis-ciが設定してあるリポジトリにpull requestする前にやるべきこと

自分の中では、これはわりと常識になっている感があるが、やってくれない人多いので、あらためて説明を書いてみる。


前提として、プログラミング言語関係ない話です。
あと、travis-ciにも限らない話です。が、全部ひっくるめてなんて呼べばいいかわからないので(オンラインCIサービスとか?)travis-ciのような何かを意味的には全部含めて、以下単にtravis-ciといいます。


これから書くことは
「プロジェクトのコミッター側のレビューのコストの減らすため」
の話です。プロジェクトによっては
「中途半端な状態でもどんどんpull reqしてもらっていい(丁寧に対応してくれる)」
とか、そもそもOSSじゃなく仕事だったり、pull reqの種類(議論するために中途半端な状態でわざとpull req)によっては当てはまらない場合があるかもしれません。


さて、本題に入ります。一言で言うと


「pull requestする前に自分のfork先のリポジトリtravis-ciをオンにして、そこでテストが通ってからpull reqしろ」


ということです。ここで
「そんなのいつもやってるよ!」
「あー、そういうことね」
と理解した人はこの先読む必要ないでしょう。以下、解説。


まず、プロジェクトによって、ビルドやテスト方法なんて様々ですね?単なるテストだけではなく

  • 独自のコード生成タスク
  • コードのスタイルチェック
  • 色んな環境(JVMや言語のversion、異なるデータベース)毎のテスト

など、例を上げればキリがないほど、多種多様なタスクが設定されている場合があります。

そんなのを、ローカルで完璧にテストするのはわりと難しい場合がありますね?そして、ローカルで通ったつもりでも、例えばScalaの場合は、ivyのキャッシュがたまたま効いていて、pull reqしてみたらresolverが足りないことが判明、なんてこともあります。


さて、pull reqしたあとに単純なミスが発生して、ビルドが通っていないとなると、レビュアーの負担が増えます。レビュアーからすると、できればそんな単純なミスはなしで、最低限テストが通る状態のpull requestもらうほうが望ましいのは、言うまでもありません。

「レビュアーの負担を出来るだけ減らす」

という観点からは、pull reqするリポジトリtravis-ciが設定されていたら、forkした先のtravis-ci上でテストを通してからpull reqすべきでしょう。




あと、逆に言うと

「これを想定してない .travis.yml の書き方をしているプロジェクト」

をたまに見かけるのですが、できれば、これが簡単にできるようになっていて欲しい・・・。

「これを想定してない」とは、たとえば
「ビルドするbranch名がwhitelist方式で管理されていて、branch名を合わせるか、一時的に.travis.yml変えないとビルドが走らせられない」
などです。あとは

「必ずircやemailで通知が飛ぶような設定がされている」

などもありますが、これは、自分が送る立場の場合


「まぁ多少迷惑かけるけど、これを想定せずに.travis.yml書いてるほうが悪いとも言えるし、fork先のリポジトリtravisから、どんどんメール送りつけよう!」


みたいな図々しい態度でいます(ぇ


ちなみに、forkしてすぐ後だと、自分のリポジトリ一覧にでないので、syncボタン押す必要あります(以下の画像の真ん中あたり)
*1





この程度で説明終わりですが、こういう視点が全く無かった人の参考になれば幸いです。

*1:現状のtravisは、数時間に1度程度の間隔でリポジトリ一覧を取得してるみたい