Ruby deploys temporarily disabled

Re:Ruby deploys temporarily disabled by mildavw on Wednesday January 30, 2013 @02:40PM (#5141292)

Survey: Do you depend on RubyGems for every deploy? Or do you have your own gem server? Or cache them at some point earlier in your pipeline?

We rely on RubyGems and had a meeting yesterday about changing that when one of the gems we use had a version just disappear.

[ Parent | on HN ]

Re:Ruby deploys temporarily disabled by Corrado on Wednesday January 30, 2013 @03:15PM (#5141517)

I was looking for a RubyGems proxy a couple of weeks ago but was unable to find anything suitable. What I would like to find is something similar to Artifactory for Maven. You include the proxy in your Gemfile and if it doesn't have the Gem it downloads it from RubyGems and caches it locally.

This type of proxy wouldn't help in this particular case but it would allow you to keep traffic to RubyGems.org down and also give you the ability to easily host private Gems.

[ Parent | on HN ]

Re:Ruby deploys temporarily disabled by pmahoney on Wednesday January 30, 2013 @07:34PM (#5142684)

I, too, would love something like this.

You're probably aware, but it's possible to host private gems in a simple static webserver. We have our CI server copy gems over and run a script that calls "gem generate_index -d /path/to/gems".

Completely featureless, of course. Lacks the newer rubygems.org api (so bundler is stuck downloading the whole index), and obsolete versions will stick around without manual intervention (which, if you have too many, is a pathological case for bundler's resolver).

[ Parent | on HN ]

Re:Ruby deploys temporarily disabled by scotje on Wednesday January 30, 2013 @02:52PM (#5141379)

If you use bundler, "bundle package" can help reduce or eliminate your dependency on external gem repositories. At least for deployments.

I generally try to follow the "vendor everything" philosophy: http://ryan.mcgeary.org/2011/02/09/vendor-everything-still-a...

[ Parent | on HN ]

Re:Ruby deploys temporarily disabled by redeemedfadi on Wednesday January 30, 2013 @03:16PM (#5141534)

I couldn't get through this whole article due to the dude in the corner staring at me... :-/

[ Parent | on HN ]

Re:Ruby deploys temporarily disabled by Legion on Wednesday January 30, 2013 @04:05PM (#5141759)

Not that this line of discussion is particularly constructive, but I agree. I'm not sure why someone would think a giant head staring at the reader is a good idea, but it's not.

On a 27" monitor, it's almost like a child sized head right up in your face. I can only imagine it being even worse on bigger screens.

[ Parent | on HN ]

Re:Ruby deploys temporarily disabled by xanido on Wednesday January 30, 2013 @10:06PM (#5143201)

    document.getElementById('mugshot').remove()

[ Parent | on HN ]

Re:Ruby deploys temporarily disabled by prodigal_erik on Wednesday January 30, 2013 @05:20PM (#5142133)

We treated .gems like source tarballs (they can't even express non-Ruby dependencies, Gem::Specification#requirements are treated as comments), and only used rubygems.org for newer versions of our dependencies to be packaged as .rpms for test and production deployments. I found that to be much more sane than bypassing the system package manager and smuggling random crap onto dev servers, much less production.

[ Parent | on HN ]

Re:Ruby deploys temporarily disabled by pbiggar on Wednesday January 30, 2013 @02:41PM (#5141302)

Gems get yanked. Its a danger of this approach.

[ Parent | on HN ]

Re:Ruby deploys temporarily disabled by kawsper on Wednesday January 30, 2013 @07:27PM (#5142671)

And stuff get yanked for good reasons.

[ Parent | on HN ]