travis-ciのキャッシュ機能を使って、Scalaプロジェクトのビルドを少しだけ高速化する

以下を参照


該当部分を抜粋

cache:
  directories:
    - $HOME/.ivy2/cache
    - $HOME/.sbt/boot

script:
  - sbt ++$TRAVIS_SCALA_VERSION test # 各々のプロジェクトのテスト用コマンドの最後に、以下の2行追加
  - find $HOME/.sbt -name "*.lock" | xargs rm
  - find $HOME/.ivy2 -name "ivydata-*.properties" | xargs rm

travisの中の人、かつ以前も何回かscalazのtravisの設定関連でpull reqくれた人*1がpull reqくれて、今のScalazではこうなってます。細かい仕組み自分もそれほどよくわかってませんが、少しでも短くしたい人は真似してみればいいのではないでしょうか。

実際どのくらい短くなるのか?というと

ちょっとわかりづらいですが、1975, 1982番目が該当pull reqなので、

  • キャッシュ設定前 14:48, 14:53, 15:27, 13:50, 13:15, 16:34, 14:12
  • キャッシュ設定後 9:51, 9:41, 10:15, 10:30, 10:11, 10:59, 10:55

となってます。この時間は、それぞれの合計時間です。これ書いてる時点のscalazのデフォルトのbranchでは、jdkのversionによってのクロスビルドはしていなく、Scala2.10と2.11系でのクロスビルドです。
よって、上記の時間を2で割って

  • 今までは6分から8分程度かかっていた
  • キャッシュ使うようになったら5分程度になった

という結果です。1〜2分は短くなるようです。多分、この「1〜2分短くなる」というのは、他のプロジェクトでも同じ結果が出ると思います。(scalaz特有のことをしてるわけではないので)。$HOME/.ivy2/cache もキャッシュしてるので、依存ライブラリが多い場合は、もっと短くなるかもしれません。
キャッシュがおかしくなったら、手動でも消したりできるみたいですし

もし少しでも速くしたい人は、気軽に試してみるといいと思います。

ただし、ivy2/cache をキャッシュしてるので、これをやってしまうと「resolverの追加忘れ」が、検知できなくなってしまう可能性があるかもしれません?



ところで、"$HOME/.sbt/boot/scala-$TRAVIS_SCALA_VERSION" の部分の設定は、sbtがビルドされてるScalaのversion?な気がして、だとしたら間違ってる気がするのですが・・・?


追記:
eed3si9nさんとgitterで話した結果、やはり "$HOME/.sbt/boot/scala-$TRAVIS_SCALA_VERSION" は間違いっぽい(TRAVIS_SCALA_VERSIONの部分にくるのは、sbtが使用しているScalaのversion)という、自分の予想が正解だったようなので、修正しました

*1:たぶん、travisの中でScalaのビルドをある程度担当してる人みたい