Travis-ci環境からdebuggerは外しておけ

travis-proがRuby1.9.3-p194 => Ruby1.9.3-p327になってdebuggerビルドできなくてテスト落ちて右往左往した。

正しくやるべきこと

Travis-ci環境でdebuggerは要らないので外しましょう
http://about.travis-ci.org/docs/user/languages/ruby/#Exclude-non-essential-gems-like-ruby-debug-from-your-Gemfile
having trouble getting ruby gem debugger installed – Google Groups

debuggerのビルドにはrubyのヘッダーが必要で、ヘッダーはdebugger-ruby_core_sourceから持ってきてて、debugger-ruby_core_sourceがrubyのバージョンより遅れると、debuggerがビルド出来ない

なぜか外れない

外したつもりだけど外れないのなんで?

https://github.com/sanemat/soryu/blob/4a50db760fafce8b4a5dce2756b2559146d9e692/www.ohmyglasses.jp.travis.yml

Gemfileのgroup :development, :test に入ってたのを group :development に移した
でも、何か別のgemがdebuggerに依存してるぽくてtravis-ci環境でもdebuggerが入ってしまう

どうやって調べればいいのかよくわからん pry-* あたりかなーあやしいの
group :production, :staging これ悪さしそうな気がする なんだ :staging
bundler/capistrano が想定してるの:development, :test, :productionだけな気がする
なんでbundle のoptionってwithout指定なんだろう 激しくめんどくさい

暫定対処したリスト

暫定対処 現在2012-11-18

debugger1.2.2に上げるとdebugger-ruby_core_source1.1.5に上がりビルドできるようになる
$ bundle update debugger
debugger (1.2.2)
debugger-linecache (1.1.2)
debugger-ruby_core_source (1.1.5)

暫定対処1

Gemfileからdebugger消してもbundleすると何かが入れて、なおかつtravisで–without development productionなのにインストールしようとしてエラーになるので、Gemfileからdebugger消して、Gemfile.lock手動で編集して >< debugger, columnize, debugger-linecache, debugger-ruby_core_source消す ><
なんでこれで行けたんだ? と今となっては思うけど作業してる時は焦ってた

暫定対処2

debugger-ruby_core_source に Ruby 1.9.3-p327 のヘッダ追加してみた – そんなこと覚えてない http://blog.eiel.info/blog/2012/11/10/debugger-ruby-core-source-on-1-dot-9-3-p327/

みて eiel/debugger-ruby_core_source 指定してみたけどうまく行かなかった。後日取り込まれたcldwalker/debugger-ruby_core_source のgemではうまくいったから、自分のGemfile書き方がまずかったっぽい。debugger-ruby_core_sourceのpull request見ててこっちならうまく行ったので、別の人のforkを採用。

gem ‘debugger-ruby_core_source’, github: ‘hosamaly/debugger-ruby_core_source’, branch: ‘1.9.3p327-headers’
gem ‘debugger’

暫定対処3

上記現在2012-11-18に書いたもの

結論

Gemfileメンテナンスしないとよくわからなくなる
travis-ci依存度高いとtravisに振り回される
何がtravis-ciで動くべきで、手元のtestで何が動くべき、production, jenkinsで何が動くべき、で整理しないとだ〜

後日談

travisでrubyのバージョン指定すれば?

パッチレベルまで指定できない。Ruby1.9.3-p194のインスタンスにはp194しか入ってなくて、Ruby1.9.3-p327のインスタンスにはp327しか入ってないので、.travis.ymlのrvmの指定に1.9.3-p194まで書くと落ちる。before_scriptに – rvm install 1.9.3-p194 ってあらかじめ書いておけばいいけど、毎回rubyのビルドから始まる可能性がある、そういうの好みじゃない。

therubyracerもsegmentation faultになりましてね

travisでtherubyracer本当に要るんだろうか? 要るとしてもtravis-ciならnode使えばいい感だがそうも言ってられないので。ふぇぇ

gem ‘therubyracer’, ‘0.11.0beta8’
gem ‘libv8’, ‘~> 3.11.8’

広告

Travis-ciにping打ってもう一度ビルドさせたい

travis-ciがpull requestの最後のコミットに反応しなくて、もしくは違うコミットに反応してpassのはずなのにfailで終わってしまうときtravis起こすためだけの空コミット(READMEに改行足してみるなど)入れてしまうんだけどもっと正攻法があるはず ビルドのトリガーにhook以外にpingうつのが合った気がするんだけど、それが一度failになったやつももう一度やってくれる簡単なインターフェース有りそうだよなー。

masterに変なコミット入れません以前に、travis用の確認用コミットが入りますとか悲しい

最後のコミット、コメントちょっと編集してsha1変えて push -f ? それもキモくないか 空コミットよりマシか

Edited 2012-11-17 11:24
空コミットよりマシなのでgit commit -v –amend でコメント変えてsha1変えてpush -f で運用することにした!

Edited 2012-11-17 11:27
git のpush だるくて(リモートのブランチ名なぞ覚えてない) historyから補完して打っちゃうこと多くて意図しないpush -f入るの怖いんだよね そうでなくてもよく注意力散漫であってなるのに。

My biggest contribution day for php!

Today is my biggest contribution day for php ever! Community people gave me a lot of advices. I’m very very excited!! My piece of code will be part of travis-ci!

– php-build (https://github.com/CHH/php-build)
“Builds multiple versions of PHP.”
Pull Request #59: Add comment out on extension_dir in php.ini. especially for php5.2. by sanemat · CHH/php-build
https://github.com/CHH/php-build/pull/59
All people can use php.ini in php5.2! … php5.2 ;(

– travis-cookbooks (https://github.com/travis-ci/travis-cookbooks)
“collections of Chef cookbooks for setting up, VMs for running tests (CI environment)”
Pull Request #57: Add php.ini suffix. by sanemat · travis-ci/travis-cookbooks
https://github.com/travis-ci/travis-cookbooks/pull/57
All people can use default php.ini on php5.2! … php5.2 ;(

Yeah!

travis-ciでenvを掛け算式に使えたらいいんじゃない

sorcery見てて、sorceryに限らず、例えばrailsのバージョンをtravis-ciのenvみたいなのでマトリックス式に網羅出来ればいいなーとちょっと思った
– env
– s/gem ‘rails’/gem ‘rails’, ‘~> 3.1’/ Gemfile
– s/gem ‘rails’/gem ‘rails’, ‘~> 3.2’/ Gemfile
ってpsuedocodeなイメージで もちろん試してません
Gemfileの直書き換えは雑な気もするけどbundlerで同じレイヤで扱うからしかたないのかな
いまのとこ

同時に、.travis.ymlだけでもうすでにおなかいっぱいなのにこれ以上 travis specificなbad know-how が貯まるのはなんか違うとも思う。bad know-howって高林さんの造語なんだ すげえ http://q.hatena.ne.jp/1142543835