Bundler: 在更改 Gemfile 之后,您正试图在部署模式下安装

我对 Bundler 和 Capistrano 还是个新手,我想把他们结合起来。当我尝试部署时,我得到的信息是:

在更改 Gemfile 之后,您正试图在部署模式下安装。在其他地方运行‘ bundle install’并将更新后的 Gemfile.lock 添加到版本控制中。

我不知道如何满足抱怨的系统,我也不明白为什么会出现抱怨,因为我在 医生上读到:

如果存在 Gemfile.lock,并且您已经更新了 Gemfile (5) , Bundler 将对所有 gem 使用 Gemfile.lock 中的依赖项 您没有更新,但是将重新解析 gems 的依赖项 你可以找到更多关于这次更新的信息 保守更新下列程序。

我解释说,这意味着捆绑包可以处理的事实,我的 Gemfile 是不是什么它的期望。有人帮忙吗?

规格: Ruby 1.9.3,Rails 3.2.3,Capistrano 2.12.0,Bundler 1.1.4,Windows 7,部署到 Posix 机器上。

编辑: 我的 Gemfile 包含如下逻辑块:

unless RbConfig::CONFIG['host_os'] === 'mingw32'
# gem 'a' ...
end
67787 次浏览

I ran into something similar before. One way to fix it, I think, but may take more space on your server than you want, is to run

bundle install --deployment

and then try to deploy. This does something like install all of your gems into the vendor folder, which I believe is generally good to avoid... but will still probably work. My app used to behave like this, my solution was removing exact versions to download from in my Gemfile, and then rebundling and deploying.

gem 'rails_admin', :git => 'git://github.com/sferik/rails_admin.git', :branch => 'master'

to

gem 'rails_admin'

Or you can do what it suggests, and Git your project off the production server onto a local machine, bundle it, and then repush onto your server. This solution might not be 100% correct but some of it worked for me... just thought I'd share. Goodluck

The error message you're getting regarding Gemfile.lock may be because your Gemfile and Gemfile.lock don't agree with each other. It sounds like you've changed something in your Gemfile since you last ran bundle install (or update). When you bundle install, it updates your Gemfile.lock with any changes you've made to Gemfile.

Make sure you run bundle install locally, and check-in to source control your newly updated Gemfile.lock after that. Then try deploying.

Edit: As recognised in the comments, a conditional in the Gemfile resulted in a valid Gemfile.lock on one platform, invalid on another. Providing a :platform flag for these platform-dependent gems in the Gemfile should solve the asymmetry.

When you see the following...

$ 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)
. . .

... Then, the problem is most likely that you have outdated .gem files in your vendor/cache directory.

Perhaps, you previously ran $bundle install --deployment which put some "outdated" .gem files in the cache?

In any case, you can get past this error by running: bundle install --no-deployment

That's one of the many great things about Rails... the error messages often tell you exactly what to do to fix the problem.

Another cause of the error:

This is a bit foolish, but i'm sure someone else will make the same mistake.

For Rails 4 Heroku added the gem rails_12factor. If you were using it before they added it, then you'll have these two gems:

gem 'rails_log_stdout',  github: 'heroku/rails_log_stdout'
gem 'rails3_serve_static_assets', github: 'heroku/rails3_serve_static_assets'

You have to remove them when you add the new one. (they're included). I think you can get away with it until you touch them lines in your gem file, then Heroku notices the duplication and cries out with the above error.

good luck with Rails 4.

I ran into this deploying a Nesta app after some gem updates. What worked for me was to delete the Gemfile.lock, run bundle install to re-generate it, and deploy again.

I ran into a similar issue however I did both bundle install and bundle update and Heroku still rejected my push.

I fixed the issue by just deleting Gemfile.lock and then running bundle install again. I then added, committed, and pushed that to my git repo. After that I had no problem pushing to Heroku.

vi .bundle/config

change the BUNDLE_FROZEN option from '1' to '0'

do "bundle install"


OR

run "bundle config"

see if the "frozen" value is true set it to false

bundle config frozen false

In our case we were using a feature that wasn't available in an old version of bundler which ran on our production machine. Therefore it was enough to upgrade bundler, i.e. do a gem update bundler.

The solution for me was slightly different than the others listed here. I was trying to upgrade from sidekiq to sidekiq-pro (which requires bundler 1.7.12+), but I kept getting the "You are trying to install in deployment mode after changing your Gemfile" message from travis-ci

Inspecting the console output of travis-ci revealed that an older version of bundler was being used.

In my case, I had to edit the travis.yml file to add:

before_install: - gem update bundler

This forced travis-ci to use the latest version of bundler, and made the error message go away.

rm -fr .bundle

Fixed the problem for me.

Watch out for global Bundler config.

I had a global config on my dev environment in ~/.bundle/config that I did not have in my CI / Production environment that caused the Gemfile.lock that was generated in my dev environment to be different than the one in my CI / Production environment.

In my case I was setting github.https to true in my dev environment but had no such config in my CI / Production environment. This caused the two Gemfile.lock files to be different.

My specific problem was related to what reported by @JoshPinter, i.e. dev-vs-deploy host discrepancies in the protocol used by bundler to retrieve gems from github.

To make a long story short, all I had to was modify the following Gemfile entry...

gem 'activeadmin', github: 'activeadmin'

...to this secure syntax (see reference):

gem 'activeadmin', git: 'https://github.com/activeadmin/activeadmin.git'

And my deployments are back to normal.

for heroku, you don't have to change the syntax in the Gemfile. you can just add BUNDLE_GITHUB__HTTPS (note the double underscore) as an environment variable and set it to true (in your heroku app's dashboard under the Settings tab in the Config Vars section). this will switch the protocol from git:// to https:// for all such requests.

This might be a dangerous idea, but if absolutely must test something in a production deploy environment, you can edit the .bundle/config file

# This value is normally '1'
# Set it to '0'
BUNDLE_FROZEN: '0'

Now invoke bundle, in my case I needed to update a specific gem, so this my command

RAILS_ENV=production bundle update <whatever gem>

You should probably change it back after the update, so things work like you expect, afterwards. Again, this is probably unsupported, and YMMV

I had the error message when attempting push to Heroku. I found the following solution fixed.

  1. Git pull origin master
  2. Git status
  3. Git commit
  4. Git push origin master
  5. Git push heroku master

This issue can be related to submodules pointing to old versions of code. For me, I resolved this issue by updating my submodules

If you have submodules, try running:

git submodule update --init

bundle install

After this command, you can do your normal bundle install again:

bundle install --no-deployment

I read a dozen solutions on different resources but didn't find exactly what could help me in this situation

So I did find a solution. Exactly saying i read the error message attentively and there was a sollution: Run bundle install elsewhere. "Elsewhere" was my Cloud9 where i developed my app. So my steps

  1. copy Gemfile and Gemfile.lock from server to local machine with rsync command
  2. insert these two files into my RoR project (i used Cloud9)
  3. open Gemfile and make changes that i want. In my case i added gem 'thin'
  4. in terminal cd to my app on Cloud9 and run bundle install. in this case you will have a changed version of Gemfile.lock
  5. copy new Gemfile and Gemfile.lock on server using rsync
  6. cd to my app folder and again run bundle install --deployment --without development test DONE! Wish GOOD luck for all!

I don't care. This is what I did. It fixed it.

rm -rf .bundle
rm -rf Gemfile.lock
bundle install

The error message for the command bundle install in windows 10 (rails v-7) was like

You are trying to install in deployment mode after changing
your Gemfile. Run `bundle install` elsewhere and add the
If this is a development machine, remove the C:/Users/friends/Gemfile freeze
by running `bundle config unset deployment`.


The dependencies in your gemfile changed


You have added to the Gemfile:
* pg


You have deleted from the Gemfile:
* sqlite3 (~> 1.4)

So I did exactly the error message asked me to do. Ran the following command

bundle config unset deployment

And then I again ran `bundle install and then it worked