scalaとか・・・

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

travis-ci | 14:48 |

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

前提として、プログラミング言語関係ない話です。

あと、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

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

ツイートする