search

rubygems / bundler

Manage your Ruby application's gem dependencies
https://bundler.io
MIT License
4.89k stars 2k forks source link

Capistrano Script running install against :current_release instead of :latest_release #769

Closed wleeperogs closed 13 years ago

wleeperogs commented 13 years ago

This has the net effect of when you deploy it runs against the Gemfile of the most recently deployed version rather than the one we are attempting to deploy. It looks like when refactoring it was switched from using fetch(:latest_release) to fetch(:current_release).

Using Version 1.0.2 as a gem Using Capistrano V2.5.19 Ruby 1.8.7 Rails 2.3.8

indirect commented 13 years ago

Capistrano uses current_release for the migration task. Since you are the only person to report this (and since I have used the bundle:install task just today, and it worked fine), I suspect you may have something strange going on with your deploy.rb.

wleeper commented 13 years ago

bundle:install works fine, it is bundle:deploy that has the problem. Also I can do a cap deploy with bundle version 1.0.0 with no issues, but version 1.0.2 has the problem below

Here is a screen grab. Note the difference the folder used for the Gemfile location vs the location that Git checked the code out to: mkdir -p /var/www/rails/ARMS/releases/20101015162422/public &&\n mkdir -p /var/www/rails/ARMS/releases/20101015162422/tmp &&\n ln -s /var/www/rails/ARMS/shared/log /var/www/rails/ARMS/releases/20101015162422/log &&\n ln -s /var/www/rails/ARMS/shared/system /var/www/rails/ARMS/releases/20101015162422/public/system &&\n ln -s /var/www/rails/ARMS/shared/pids /var/www/rails/ARMS/releases/20101015162422/tmp/pids" servers: ["arms-dev"] [arms-dev] executing command command finished

indirect commented 13 years ago

There is no bundle:deploy task. Furthermore, when I deploy, bundle install uses the same directory as the rest of the deploy tasks. Can you reproduce this with another application, or using a minimal deploy.rb?

cgriego commented 13 years ago

Yes, using :latest_release is by design.

indirect commented 13 years ago

? I thought it wasn't using latest_release. Confused...

cgriego commented 13 years ago

Sorry, I mispoke. Meant to say that current_release is by design.

wleeper commented 13 years ago

Sorry for the confusion. I have another push to do for a different project i will check tonight, but when you add in the bundler/capistrano to your Capistrano script it adds a bundle:install after the deploy:update. It is this scenario that is having the problem. When it runs during the deploy it is updating the :current_release which is fine if you are doing a stand alone bundle:install, but not if you are doing a deploy since the current in that case is not the version you are deploying. I looked at the source for V1.0.0 and it has the code as :latest_release, but when the code was refactored on 9/24 it was changed to :current_release as part of that refactoring.

indirect commented 13 years ago

cgiego, maybe you could explain the design decisions?

wleeper, I'm using 1.0.2 and it's working fine for me when it runs automatically as part of cap deploy. That's why I'm wondering if something strange could be going on with your cap recipes.

wleeperogs commented 13 years ago

Finally found the likely culprit.

require 'capistrano/ext/multistage'

Other than that I have pretty vanilla Capistrano script. I verified using another project that this is not an issue at least for Bundler.

Thanks for looking into this.

indirect commented 13 years ago

Huh. Very odd, because I'm using multistage and bundler together with no problems. Thanks for reporting back!

cap10morgan commented 13 years ago

I'm confused. Is this a problem in bundler or not? If not, any tips for fixing it? We had to rip out bundler/capistrano because of this.

indirect commented 13 years ago

cap10morgan, Bundler uses current_release deliberately. In a plain Capistrano setup, current_release is the release that was just deployed. If your current_release is not the release that you just deployed, something is going on with your Capistrano setup that you'll need to resolve.

If you're unwilling to debug your Capistrano setup, you may be able to get away with simply creating your own cap task that runs Bundler against latest_release instead.