私はbundlerとcapistranoにかなり慣れていないので、一緒に使用しようとしています。デプロイしようとすると、次のメッセージが表示されます。
Gemfileを変更した後、展開モードでインストールしようとしています。別の場所で「バンドルインストール」を実行し、更新されたGemfile.lockをバージョン管理に追加します。
文句を言っているシステムを満足させる方法がわからず、 doc :
Gemfile.lockが存在し、Gemfile(5)を更新した場合、Bundlerは、更新していないすべてのgemに対してGemfile.lockの依存関係を使用しますが、更新したgemの依存関係を再解決します。この更新プロセスの詳細については、保守的な更新を参照してください。
これは、Gemfileが予期したものではないという事実をBundlerが処理できることを意味すると解釈します。何か助け?
仕様:Ruby 1.9.3、Rails 3.2.3、Capistrano 2.12.0、Bundler 1.1.4、Windows 7、 Posixマシンへのデプロイ。
Edit:Gemfileには次のような論理ブロックが含まれています。
unless RbConfig::CONFIG['Host_os'] === 'mingw32'
# gem 'a' ...
end
Gemfile.lock
に関して表示されるエラーメッセージは、Gemfile
とGemfile.lock
が互いに一致しないことが原因である可能性があります。最後にbundle install
(またはupdate
)を実行してから、Gemfileで何かを変更したようです。 bundle install
を実行すると、Gemfileに加えた変更でGemfile.lockが更新されます。
必ずbundle install
をローカルで実行し、その後、チェックインして、新しく更新されたGemfile.lock
をソース管理してください。その後、展開してみてください。
Edit:コメントで認識されているように、Gemfileの条件により、あるプラットフォームでは有効なGemfile.lockが、別のプラットフォームでは無効になりました。 Gemfileでこれらのプラットフォーム依存のgemに :platform フラグを提供すると、非対称性が解決されます。
vi .bundle/config
bUNDLE_FROZENオプションを「1」から「0」に変更します
「バンドルインストール」を行う
OR
「バンドル設定」を実行します
「凍結」値がtrueかどうかを確認し、falseに設定します
バンドル構成の凍結false
開発環境で生成された~/.bundle/config
がCIの環境とは異なる原因となるGemfile.lock
の開発環境に、CI /実稼働環境にはないグローバル構成がありました。/本番環境。
私の場合、開発環境でgithub.https
をtrueに設定していましたが、CI /実稼働環境ではそのような構成はありませんでした。これにより、2つのGemfile.lock
ファイルが異なっていました。
次が表示されたら...
$ bundle install
You are trying to install in deployment mode after changing
your Gemfile. Run `bundle install` elsewhere and add the
updated Gemfile.lock to version control.
If this is a development machine, remove the Gemfile freeze
by running `bundle install --no-deployment`.
You have added to the Gemfile:
* source: rubygems repository https://rubygems.org/
* Rails (~> 3.2)
. . .
...次に、問題は、vendor/cacheディレクトリに古い.gemファイルがある可能性が高いことです。
おそらく、以前に$bundle install --deployment
いくつかの「古い」.gemファイルをキャッシュに入れましたか?
いずれの場合でも、次のコマンドを実行することでこのエラーを回避できます:bundle install --no-deployment
これはRailsのすばらしい点の1つです。エラーメッセージは、多くの場合、問題を解決するために何をすべきかを正確に示します。
私の特定の問題は、@ JoshPinterによって報告されたものに関連していました。すなわち、dev-vs-deploy githubからgemを取得するためにbundlerが使用するプロトコルのホストの不一致です。
簡単に言えば、次のGemfile
エントリを変更するだけでした...
gem 'activeadmin', github: 'activeadmin'
...この安全な構文( 参照を参照 ):
gem 'activeadmin', git: 'https://github.com/activeadmin/activeadmin.git'
そして、私の展開は正常に戻りました。
私にとっての解決策は、ここに挙げた他の解決策とはわずかに異なっていました。 sidekiqからsidekiq-pro(Bundler 1.7.12+が必要)にアップグレードしようとしていましたが、travis-ciから「Gemfileを変更した後、展開モードでインストールしようとしています」というメッセージが表示され続けました。
Travis-ciのコンソール出力を調べると、古いバージョンのバンドラーが使用されていたことが明らかになりました。
私の場合、travis.ymlファイルを編集して以下を追加する必要がありました。
before_install: - gem update bundler
これにより、travis-ciは最新バージョンのバンドラーを使用するように強制され、エラーメッセージが消えました。
rm -fr .bundle
私の問題を修正しました。
私たちのケースでは、本番マシンで実行されていた古いバージョンのバンドラーでは利用できなかった機能を使用していました。したがって、バンドラーをアップグレードするだけで十分でした。つまり、gem update bundler
。
エラーの別の原因:
これは少しばかげていますが、他の誰かが同じ間違いを犯すと確信しています。
For Rails 4 Herokuがgem Rails_12factorを追加しました。追加する前に使用していた場合、次の2つのgemがあります。
gem 'Rails_log_stdout', github: 'heroku/Rails_log_stdout'
gem 'Rails3_serve_static_assets', github: 'heroku/Rails3_serve_static_assets'
新しいものを追加するときにそれらを削除する必要があります。 (含まれています)。 gemファイル内の行に触れるまでは、Herokuが重複に気付き、上記のエラーで叫ぶまで、それを回避できると思います。
Rails 4。
これは危険な考えかもしれませんが、運用展開環境で何かをテストする必要がある場合は、.bundle/configファイルを編集できます
# This value is normally '1'
# Set it to '0'
BUNDLE_FROZEN: '0'
バンドルを起動します。私の場合、特定のgemを更新する必要があったので、このコマンドを
Rails_ENV=production bundle update <whatever gem>
おそらく更新後に元に戻す必要があるため、その後は期待どおりに機能します。繰り返しますが、これはおそらくサポートされておらず、YMMV
以前に似たようなものに遭遇しました。それを修正する1つの方法は、私は思うが、あなたが望むよりもあなたのサーバー上でより多くのスペースを取るかもしれない、実行することです
bundle install --deployment
そして、展開を試みます。これは、すべてのgemをベンダーフォルダにインストールするようなことをします。これは一般的に避けるのが良いと思います...しかし、おそらくうまくいくでしょう。私のアプリは以前はこのように振る舞っていましたが、私の解決策は、Gemfileからダウンロードする正確なバージョンを削除してから、再バンドルしてデプロイすることでした。
gem 'Rails_admin', :git => 'git://github.com/sferik/Rails_admin.git', :branch => 'master'
に
gem 'Rails_admin'
または、提案されていることを実行し、プロジェクトを実動サーバーからローカルマシンにGitし、バンドルしてから、サーバーに再プッシュすることができます。この解決策は100%正確ではないかもしれませんが、一部はうまくいきました...共有したいと思っただけです。幸運を
私はさまざまなリソースで多数のソリューションを読みましたが、この状況で私を助けることができるものを正確に見つけませんでした
だから私は解決策を見つけました。丁寧にエラーメッセージを読んだところ、解決策がありました:他の場所でバンドルインストールを実行 「Elsewhere」は、アプリを開発したCloud9でした。だから私のステップ
rsync
コマンドを使用して、GemfileとGemfile.lockをサーバーからローカルマシンにコピーしますbundle install
。この場合、Gemfile.lockの変更済みバージョンになりますrsync
を使用するサーバー上のGemfileおよびGemfile.lockbundle install --deployment --without development test
完了!幸運を祈ります!このコマンドの後、通常のバンドルインストールを再度実行できます。
bundle install --no-deployment
この問題は、古いバージョンのコードを指すサブモジュールに関連している可能性があります。私にとっては、サブモジュールを更新することでこの問題を解決しました
サブモジュールがある場合は、実行してみてください:
git submodule update --init
bundle install
Herokuにプッシュしようとしたときにエラーメッセージが表示されました。次の解決策が修正されました。
herokuの場合、Gemfile
の構文を変更する必要はありません。環境変数としてBUNDLE_GITHUB__HTTPS
(二重アンダースコアに注意)を追加し、true
に設定できます(Config Vars
セクションのSettings
タブの下のherokuアプリのダッシュボードで) )。これにより、そのようなすべてのリクエストに対してプロトコルがgit://
からhttps://
に切り替わります。
私は同様の問題に遭遇しましたが、両方をやりましたbundle install
およびbundle update
とHerokuはまだ私のプッシュを拒否しました。
Gemfile.lockを削除してからbundle install
もう一度。次に、それをgitリポジトリに追加、コミット、およびプッシュしました。その後、Herokuにプッシュしても問題ありませんでした。
いくつかのgemの更新後、Nestaアプリのデプロイに遭遇しました。私のために働いたのはGemfile.lockを削除する、実行bundle install
を再生成し、再デプロイします。