自分の中では、これはわりと常識になっている感があるが、やってくれない人多いので、あらためて説明を書いてみる。
前提として、プログラミング言語関係ない話です。
あと、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
この程度で説明終わりですが、こういう視点が全く無かった人の参考になれば幸いです。
