32

Can not update gems on production server.

I've tried bundle install --deployment and bundle install --without development test

But keep getting:

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

EDIT

I don't know if this is correct, but needed a quick fix. I ran bundle install --no-deployment then bundle update then ran bundle install --deployment again

Kashyap
  • 15,354
  • 13
  • 64
  • 103
pcasa
  • 3,710
  • 7
  • 39
  • 67

7 Answers7

47

The instructions are probably a bit confusing. It's saying that you've modified your Gemfile on your development machine and just pushed those changes rather than running bundle install BEFORE committing the changes.

By running bundle install you will update your Gemfile.lock file. This should be pushed to your server as it's more important than Gemfile. Consider the Gemfile the plans for the Gemfile.lock file.

Always remember to:

  1. Run bundle install if you change your Gemfile, even just to make sure. If it's too slow, pass --local through which forces it to only use local gems to resolve its dependencies.
  2. Commit both the Gemfile and Gemfile.lock file to your repository
  3. Deploy both the Gemfile and Gemfile.lock to your production servers to ensure that they're running the exact same dependencies as your development environment.

Running bundle update by itself can be construed as dangerous that will update all the dependencies of your application. It's mainly dangerous if you don't have solid version numbers specified in the Gemfile. I wrote about it here.

Ryan Bigg
  • 106,965
  • 23
  • 235
  • 261
  • OK, I think its starting to make sense. I did skip Gemfile.lock thinking that since server was production i should rely on that more. So my mistake was not uploading the gemfile.lock? Fortunately, I'm early in the game if I have to rebuild server. – pcasa Jul 22 '11 at 06:02
  • 1
    I'm getting the same error though my `Gemfile` and `Gemfile.lock` is in sync. I have even tried to delete the `Gemfile.lock` and regenerate it by running `bundle install`. But the new `Gemfile.lock` is identical bit for bit. – Thomas Watson Nov 22 '11 at 15:42
  • You might have changed Gemfile without triggering a change in Gemfile.lock. This happened to me when I moved something between the test and development groups. I ended up having to make a change that did trigger a Gemfile.lock change to get them back in sync (from bundler's perspective). – Brian Deterling Nov 05 '12 at 23:14
9

FWIW I had this problem and fixed it by removing some conditional statements from my Gemfile (conditionals on OS) and rerunning bundle.

TomL
  • 759
  • 8
  • 20
7

FYI: You can also get this error if you use source blocks like this:

source 'https://rails-assets.org' do
  gem 'rails-assets-jquery'
end

You'll see an exclamation point in the Gemfile.lock for this gem:

  rails-assets-jquery!

Just define the additional source normally, i.e.

source 'https://rails-assets.org'
gem 'rails-assets-jquery'

(BTW cf. here about using multiple gem sources.)

Jim Flood
  • 8,144
  • 3
  • 36
  • 48
  • 1
    According to the mentioned article using the non-block version of `source` is unsafe. Is there a way to use the block version? – Besi Mar 26 '15 at 12:23
  • @Besi I do not know, but Bundler should issue a warning. When it does, I plan to add the explicit :source option on the gem in question. – Jim Flood Mar 26 '15 at 15:34
  • 1
    If you are reading this and wondering what's going on. My production server system ruby is still 1.9.3 with an outdated `bundler` version. When using `source` as a block, or a key on the gem, I got this error. By defining it as an additional source, I got rid of the exclamation point as mentioned by Jim Flood, and the deployment succeeded. I'm assuming older versions of bundler simply can't handle the source block, or source hash notation. – tolgap Jun 09 '15 at 17:50
  • 1
    Another (probably better) way to resolve this problem with `source` blocks is to ensure that your bundler versions are in sync between dev/prod servers. I had this problem while running bundler 1.7.7 on a dev box, and 1.7.1 on a production server. Updating both to 1.10.4 resolved the issue. – KenB Jun 17 '15 at 14:19
4

This can be caused by an old version of the bundler gem on the server you're deploying to (in this case production). Logging into the server and running a gem update bundler resolved the issue for me. The server I was deploying to was running version 1.7.4 and the current version was 1.9.

paul
  • 5,298
  • 2
  • 18
  • 23
  • The only thing that's worked for me. I was already removed the `Gemfile.lock` and generate it again but in the server still keeping the old version. Thank you so much! – monteirobrena Jan 03 '20 at 03:17
2

I had an issue with my production server still using an old version of a gem, even though the Gemfile.lock showed the correct, updated version. My production server was running on Unicorn - and shutting down / starting it back up again fixed the issue - instead of sending the HUP signal, which did jack all to fix the issue.

James
  • 2,284
  • 1
  • 20
  • 29
1

bundle install failed on my "development" machine because of the mysql-gem on osx...

I also needed a quick fix. So I cloned the repo to a new folder on the production machine, ran "bundle install" there and committed the Gemfile.lock to the repo.

randomcontrol
  • 1,996
  • 1
  • 15
  • 11
1

I have had this problem (Ubuntu 12.10 & 12.04, one of which behind a proxy server). My problem was that I had some git:// protocols in the Gemfile. Changing this to http:// helped me get it all working.

Emil Rehhnberg
  • 941
  • 7
  • 4