まえこんな記事書きましたが
その後色々試して↓
travis-ci が sbt が起動する以前の段階で、なぜか jruby のスタックトレースを吐いただけで死んで、buildが失敗したことになっていたりする・・・(´・ω・｀)まぁα版ってことだからしょうがないんだろうけど
2012-04-26 09:07:21 via web
あーそして travis-ci さん、「行番号つけてリンク貼れて便利！」と思いきや、その部分バグっててる?(´・ω・｀)
2012-05-06 04:15:52 via web
travis-ci も heroku も sbt0.11.3 使えなくてあれだな・・・。ますます sbt-extras なしじゃやってられない
2012-05-09 22:52:46 via web
うわぁぁぁぁぁぁぁぁ・・・ travis-ci sbt0.11.3対応してすげぇーとか思ってたら、sbt0.11.2でbuildできなくなってる・・・ないわー・・・マジかよ
2012-05-14 12:13:25 via web
てかtravis-ci不安定であまり使いものにならない
不安定だったり、sbtのversionが制限あったり、上がったと思ったら古いsbtのversionサポートされなくなったり色々微妙なところもありますが、一応使ってます。
で、
.travis.yml に
language: scala
と書いてあると、デフォルトでは "sbt test" を実行するわけですが、これが実は自由にカスタマイズできることに気づいたので、デフォルトで用意されてるsbt使わずに色々やってみました。
色々試した結果、ビルド時に外部へhttpのアクセスとか特に制限ないみたいですし、基本的なシェルのコマンドはべつになんでも実行できるようなので、sbtのversionで困らないように sbt-extras を travis の仮想マシン上で毎回取得するようにしてみたら、普通にうまくいきました(｀・ω・´)ノ
これで、sbt0.12でも普通にbuildできますね。
あと、sbt-appengine 使ったプロジェクトもテストしたいなーと思いつつ、appengine の sbt plugin は APPENGINE_SDK_HOME という環境変数が定義されていてなおかつそこに指定のjarなどが存在しないと、そもそもプロジェクトのロード時 *1 にエラーになる・・・(´・ω・｀)
というわけで、色々考えてた結果、普通に直にsdkのzipをdownloadしてその場で展開して環境変数setまでやってしまったらうまくいきました↓
https://github.com/xuwei-k/githubtree/commit/b041961f5587b64d9f600fa35b62883175903894
http://travis-ci.org/#!/xuwei-k/githubtree/builds/1633191
これでいいんだろうか・・・？
というわけで、sbtのデフォルトのversionでtestするだけで困らないならいいけれど、ちょっと違うことやるにはカスタマイズして .travis.yml の scriptのところに自分で書いたほうが柔軟性あっていいですね。( g8-test や scripted-testをやる場合も .sbtrcにalias書くのではなくて )
あとちなみに、sbtの起動時のメモリをあまり大きくし過ぎると、sbtというかJVM自体が立ち上がらない*2ので注意しましょう。
またなにかあれば書きます。
