See https://github.com/cowboyd/therubyracer/issues/218.

Since therubyracer already takes a long time to compile (and with the new libv8 dependency, even waaaay more), I think it might be better for Tracks to depend on a system JavaScript runtime by default, and provide therubyracer and libv8 as optional (i.e. commented-out) components for people whose systems don't already have a runtime available. That way environments like Heroku (which specifically deprecates therubyracer) and Travis (which already has Node.js available on its worker boxes) can take advantage of native support without editing the Gemfile.

Note that this wouldn't be the only instance of Tracks depending by default on native system resources -- the database gems already have system library dependencies.

let us try first without the v8 dependency and depend on native libv8.

strange, build 65 includes the libv8 dependency and it ran completely, including the cucumber scenario's!

Also, the build you reference does not seem to time out? If you expand the last line, I do not see a timeout?

(In tracks-tickets:fbe69a9a55f74d88e0d9ab1163c15e02d4ab6147) revert last line. Travis CI can run with v8 dependency. Closes #1382

Branch: master

You're right, it is inconsistent. The build I linked in the summary does indeed fail on line 111 though.

I'm reopening this because although it's OK for the moment (only because the Travis folks seem to be following the issue and making specific allowances for it), we need to track therubyracer ticket #215 which is the root of this issue. The libv8 dependency will be changing.

we need to think about speeding up anyway, because the run (without v8 compilation) is bigger than 25min and will not exit normally on travis...

Updated therubyracer to apply the libv8 fix in 2fce79b.

Created a new ticket #1390 for the cucumber timeout.

Oops, reopening because this still needs to be addressed for 2.2.

Fixed for 2.2 in d350685.