Actually Roy, I can't really help - I shy away from using it, and everything I have in production that's still running on Rails uses a private Gem server, and we don't package the gems.
Some of that stuff sounds familiar though. I believe if the bundle is packed, there's a .bundle file, with some options that bundler reads added to the repo. Lee Hambley -- http://lee.hambley.name/ +49 (0) 170 298 5667 On 4 April 2014 18:11, Roy Miller <r...@theotherroad.com> wrote: > Gosh, I learn something new every day. I'll check out bundle_package. If > one uses that, it looks like it just work automagically, meaning Bundler > just understands that it needs to use the gem cache instead of > rubygems.org. That's nifty. Two questions for you: > > 1) Do I update the cache when I change/add a gem by running "bundle > install" and then "bundle package"? That's a little unclear on the page you > linked to. > > 2) Do I have to do anything to tell Cap to use the bundle cache, maybe set > :bundle_flags to include "--local"? The page says this: > > By default, if you simply run bundle install after running bundle package, > Bundler will still connect to rubygems.org to check whether a > platform-specific gem exists for any of the gems in vendor/cache. This > behavior can be avoided by instead running bundle install --local. Note > that this requires you to have the correctly platformed version for all of > your gems already cached. The easiest way to achieve this is to run bundle > package on an identical machine and then check in those vendored gems. > Makes me think that little "--local" tidbit has to make an appearance > somewhere. > > Thanks for the recommendation. > > > > On Friday, April 4, 2014 11:53:13 AM UTC-4, Lee Hambley wrote: > >> That sounds reasonable to me. I did introduce some new gems, so that >>> might have pushed the memory usage over the edge. >>> >> >> It happens, the weirder one is when the oomkiller kills bundler because >> you are *almost* out of memory, but you can only see the reason in some >> obscure non-standard log file. >> >> I'd love to keep using the free t1.micros, at least for testing. You >>> mention server-side bundling. Is there a way to "pre-bundle" stuff so that >>> the bundle install portion of the Cap deploy doesn't introduce this heavy >>> memory load (or take as long)? I saw some mention of being able to do this >>> ("locking" a bundle, or some such) in the past, but I gathered it's not >>> possible anymore. Or I just don't understand things well enough yet. That's >>> always a possibility. >>> >> >> Check out http://bundler.io/v1.5/bundle_package.html - it will pack all >> the gems into your Git repo, which will make it balloon a bit, but if your >> choice is "slightly slower clone/checkout" vs. "pay more", I know what I'd >> take for testing projects. >> >> Good luck, >> >> - Lee >> >> >>> O >>> n Friday, April 4, 2014 11:45:36 AM UTC-4, Lee Hambley wrote: >>> >>>> Probably you introduced new Gems, or some gems are updated, or the >>>> Rubygems index metadata just got too large. One can't really expect to >>>> server-side bundle on a t1.micro reliably. >>>> >>>> Lee Hambley >>>> -- >>>> http://lee.hambley.name/ >>>> +49 (0) 170 298 5667 >>>> >>>> >>>> On 4 April 2014 17:44, Roy Miller <r...@theotherroad.com> wrote: >>>> >>>>> Serves me right for not running my deploy for 10 days, but now when >>>>> I run it I get this: >>>>> >>>>> [15:30:41] INFO [61afb781] Running */usr/bin/env bundle install >>>>> --binstubs /var/www/wait-less/shared/bin --path >>>>> /var/www/wait-less/shared/bundle --without development --deployment* on >>>>> ec2-107-23-0-121.compute-1.amazonaws.com[15:30:41] DEBUG [61afb781] >>>>> Command: cd /var/www/wait-less/releases/20140404153040 && /usr/bin/env >>>>> bundle install --binstubs /var/www/wait-less/shared/bin --path >>>>> /var/www/wait-less/shared/bundle --without development --deployment >>>>> >>>>> [15:30:43] DEBUG [61afb781] Fetching source index from >>>>> https://rubygems.org/ >>>>> >>>>> [15:32:21] DEBUG [61afb781] Retrying git cat-file -e >>>>> 3d1afeb52e974246ec5dbe23c12147d1116195d0 due to error (2/3): >>>>> Errno::ENOMEM Cannot allocate memory - git[15:32:21] DEBUG [61afb781] >>>>> Retrying git cat-file -e 3d1afeb52e974246ec5dbe23c12147d1116195d0 due to >>>>> error (3/3): Errno::ENOMEM Cannot allocate memory - git >>>>> >>>>> >>>>> Looks like Bundler is running out of memory for some reason. I'm >>>>> running on an AWS t1.micro instance, which could be the issue, but it >>>>> worked just dandy 10 days ago, with no changes at all to the box, only >>>>> code >>>>> changed. >>>>> >>>>> Any ideas about what's causing the issue, and how to fix it? >>>>> >>>>> Roy >>>>> >>>>> -- >>>>> 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 capistrano+...@googlegroups.com. >>>>> >>>>> To view this discussion on the web, visit https://groups.google.com/d/ >>>>> msgid/capistrano/7e3d55cf-7623-47f6-831d-6b9622ab7265%40googl >>>>> egroups.com<https://groups.google.com/d/msgid/capistrano/7e3d55cf-7623-47f6-831d-6b9622ab7265%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> -- >>> 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 capistrano+...@googlegroups.com. >>> To view this discussion on the web, visit https://groups.google.com/d/ >>> msgid/capistrano/357dcc56-bb6b-491f-b519-87e4c108f102%40googlegroups.com<https://groups.google.com/d/msgid/capistrano/357dcc56-bb6b-491f-b519-87e4c108f102%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- > 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 capistrano+unsubscr...@googlegroups.com. > To view this discussion on the web, visit > https://groups.google.com/d/msgid/capistrano/4d8b11f4-951e-4490-8ae1-0f881cc05c99%40googlegroups.com<https://groups.google.com/d/msgid/capistrano/4d8b11f4-951e-4490-8ae1-0f881cc05c99%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- 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 capistrano+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/capistrano/CAN_%2BVLVGfuVFmf1xEyq-EZZ%2BDiMU2qYS9EPOnMFZKapM6cSAAg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
