I'm having problems getting the Ruby gem 'debugger' installed successfully on a travis-ci worker box.

I'm specifying the language for my worker box as node_js but Ruby is a large part of the app also.

The basic Ruby installed on travis-ci is 1.9.2-p320.

The debugger gem uses the debugger-ruby_core_source gem for access to Ruby header files however they didn't have the 1.9.2-p320
header files included yet.

So I added them in a fork referenced from this pull request:

   https://github.com/cldwalker/debugger-ruby_core_source/pull/2

I'm referencing MY version of that gem in my Gemfile before specifying the debugger gem:

   https://github.com/concord-consortium/lab/blob/master/Gemfile#L19-20

But I am still getting errors because header files can't be found building the gem debugger-linecache:

   http://travis-ci.org/#!/concord-consortium/lab/builds/1458526

Here's my travis config:

   https://github.com/concord-consortium/lab/blob/master/.travis.yml

At 10:02 PM -0400 5/28/12, Stephen Bannasch wrote:

My fork doesn't work properly ... yet ... so I'm just trying to install the Ruby gem 'debugger' in the travis before_scriptsection.

But ... on the standard Ruby installed on the travis-ci worker boxes I'll need to specify the path to the Ruby headers likethis:

  gem install debugger -- --with-ruby-include=PATH_TO_HEADERS

Are the Ruby headers for 1.9.2-p320 installed on a standard worker box?

If so where are they located?

Thanks

Stephen Bannasch:

Travis documentation explicitly asks projects to not include ruby-debug because it takes several minutes to compile linecache.

MK

Stephen Bannasch:

What is a standard worker box? There are several types of them

 * Ruby
 * JVM + Erlang + Haskell
 * PHP + Perl + Python
 * nodejs

For all of them, Rubies are provisioned using RVM and because so many native extensions install, headers are obviously available.

Relying on a specific location is a bad idea. Using Ruby's config sounds
like a better option. I still don't see why you would need ruby-debug in CI environment, given that we have been asking
people to exclude it from installing for over half a year now.

MK

At 7:53 PM +0400 5/29/12, Michael Klishin wrote:

Right now I'm specifying the language as nodejs. However I use a great deal of Ruby in the build system. I'll probably change the language to Ruby/RVM 1.9.3-p194 and install the nodejs dependencies by hand soon.

Additionallly (though not tested yet in travis) the a application also includes a rails server in the './server' dir. In the Gemfile for the rails app the debugger gem is contained in the group :development group.

Perhaps I can do this for the top-level Gemfile also -- but the Ruby code there is not running in Rails and doesn't yet have the concept of different environments.

I added the 'debugger' gem to the top-level Gemfile because it's useful for any developer working on the project.

I can also take it out and have developers install the 'debugger' gem manually -- or figure out how to easily represent different environments to bundler.

My first approach (which certainly may not be the best) was to see if there is a way to get the existing top-level Gemfile working as is.

I think the debugger needs access to headers that are only available in a source install.

Of course you are right when you say the is NO need for debugger to be installed on a CI box.

I just started using travis-ci and didn't see the warnings about not to install a debugger.

I'm not familiar with node.js projects on Travis CI but normally when using
Bundler, this is where bundler groups would come in handy.  debugger would
go in the development group in your Gemfile so Travis CI ignores it.  Debug
tools are useless in CI environments anyway.

Check out the "Dependency Management" section on this page where they talk
about ignoring ruby-debug and the like:

http://about.travis-ci.org/docs/user/languages/ruby/