bundlerの環境変数でハマった話
capistranoでrailsアプリをbundle packageを使ってデプロイしようとしてハマった話。 ちょっとまとめるのが億劫だったので、つらつらと。 困った あるプロジェクトで、capistranoのcopyストラテジーを使って デプロイしているのですが、その際に、外部へgemを取りに行かないように、 bundle package を使っています。 で、その bundle package をする部分は自前で定義していて、 下記のように単純にやっていました。 system("cd #{destination} && bundle package --all") しかしこれだと予期したように動かなかった。 想定としては、 /tmp/hogehoge/vendor/cache の下に、gem達が入るはずなのに、なぜか capコマンド実行ディレクトリ/vendor/cache に入ってし
bundle のなかで bundle する - @kyanny's blog
Bundler.with_clean_env と bundle install --gemfile について追記しました bundle exec した環境下でさらに bundle exec したいことがある。 bundle exec rake resque:work で起動した Resque ワーカーのなかで system("bundle exec rake spec") のような外部コマンドを呼び出すとか。ありますよね。ぼくは最近ありました。そしてハマった (そしてググりづらかった) のでこれ以上犠牲者を増やさないためにブログに書く。 bundler は実行時にいくつかの環境変数を定義するが、この場合問題になるのは BUNDLE_GEMFILE と GEM_HOME だ。 BUNDLE_GEMFILE は bundler が参照する Gemfile のパスで、 GEM_HOME は ge
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
