> > I wrote my own bundler recipes that essentially caches the last successful > bundle. That cache is then copied to the new timestamp release, and > rebundled for the new release. As long as no deploy failure happens then > the rebundled directory is copied back to the cache.
That sounds like something you should ask Bundler to adopt Donovan? Lee Hambley -- http://lee.hambley.name/ +49 (0) 170 298 5667 On 12 May 2013 15:36, Donovan Bray <[email protected]> wrote: > I wrote my own bundler recipes that essentially caches the last successful > bundle. That cache is then copied to the new timestamp release, and > rebundled for the new release. As long as no deploy failure happens then > the rebundled directory is copied back to the cache. > > This also means a rollback is clean, because each timestamp release has > the bundle that matches it's Gemfile.lock. > > See these links from my cap-recipes project: > > > https://github.com/donnoman/cap-recipes/blob/master/lib/cap_recipes/tasks/bundler/install.rb > > > https://github.com/donnoman/cap-recipes/blob/master/lib/cap_recipes/tasks/bundler/hooks.rb > > > > > On Sun, May 12, 2013 at 1:52 AM, Lee Hambley <[email protected]>wrote: > >> Hi Tom, >> >> The Bundler team manage the Capistrano integration, and this problem >> comes up time and time again, it's done this way so that your installed >> "RELEASE_DIRECTORY" is a completely isolated copy of your app. >> >> You'd better raise the issue with the Bundler team, or at least check >> their faq/docs to see if what you are trying to do it already possible. >> >> As for "reasons against" - just that you are going against the grain, and >> trying to "break" a reliability feature for speed, but reliable, fast, >> cheap, pick two. >> >> - Lee >> >> Lee Hambley >> -- >> http://lee.hambley.name/ >> +49 (0) 170 298 5667 >> >> >> On 12 May 2013 03:02, TomPave <[email protected]> wrote: >> >>> Hello, >>> >>> I'm trying to improve the speed of my deploy script. >>> As it is now it works perfectly, but `bundle:install` is incredibly >>> slow: it takes between 2 and 4 minutes every time. >>> >>> >>> I noticed that Capistrano doesn't use the default directory for the user >>> who executes the rack app server: ~/.rvm/.... >>> Rather, it installs the gems in the vendor folder of each release. for >>> example: >>> >>> /var/www/wonderingmachine/releases/20130512001352/vendor/bundle/ruby/2.0.0/gems/unicorn-4.6.2 >>> >>> After Capistrano has slowly run `bundle:install`, I can run it manually >>> again and as expected it only takes few seconds (it doesn't need to install >>> any new gem). >>> >>> >>> I have a Gemfile and a Gemfile.lock in my app, and they are both checked >>> in the git repository. The Gemfile.lock doesn't change that often and I >>> don't see why Capistrano should download and install all the gems each time. >>> I imagine that using the default gem directory would speed thing up, as >>> Capistrano will need to install new gems only when I want it to update >>> something (that is, when I commit an updated Gemfile.lock) >>> Is there any reason why I shouldn't do it? >>> >>> >>> >>> Anyway, I see there is a variable names "bundle_dir". >>> Could you help me set it up? >>> >>> >>> # other ENV variables are set as well >>> # >>> default_environment["GEM_HOME"] = >>> "/home/runner/.rvm/gems/ruby-2.0.0-p0" >>> default_environment["GEM_PATH"] = >>> "/home/runner/.rvm/gems/ruby-2.0.0-p0:/home/runner/.rvm/gems/ruby-2.0.0-p0@global >>> " >>> set :bundle_dir, "....?" >>> >>> Thanks a lot >>> >>> -- >>> -- >>> * You received this message because you are subscribed to the Google >>> Groups "Capistrano" group. >>> * To post to this group, send email to [email protected] >>> * To unsubscribe from this group, send email to >>> [email protected] For more options, visit this >>> group at http://groups.google.com/group/capistrano?hl=en >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "Capistrano" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >>> >>> >> >> -- >> -- >> * You received this message because you are subscribed to the Google >> Groups "Capistrano" group. >> * To post to this group, send email to [email protected] >> * To unsubscribe from this group, send email to >> [email protected] For more options, visit this >> group at http://groups.google.com/group/capistrano?hl=en >> --- >> You received this message because you are subscribed to the Google Groups >> "Capistrano" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > > -- > -- > * You received this message because you are subscribed to the Google > Groups "Capistrano" group. > * To post to this group, send email to [email protected] > * To unsubscribe from this group, send email to > [email protected] For more options, visit this > group at http://groups.google.com/group/capistrano?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Capistrano" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- -- * You received this message because you are subscribed to the Google Groups "Capistrano" group. * To post to this group, send email to [email protected] * To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/capistrano?hl=en --- You received this message because you are subscribed to the Google Groups "Capistrano" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
