Last modified: 2014-11-20 01:41:15 UTC
jenkins is still using Ruby 1.8 when generating/testing JSDuck documentation. 1.8 was EOL'd last June (https://www.ruby-lang.org/en/news/2013/06/30/we-retire-1-8-7/) and the current version is 2.1. JSDuck 4 runs perfectly well on newer versions, I think you could upgrade to at least 1.9 with no hiccups. I noticed this when looking at a segfault that happened on this job: https://integration.wikimedia.org/ci/job/mediawiki-core-jsduck/3304/console – upgrading Ruby will probably fix this kind of problems too.
On Ubuntu Precise the default ruby version is 1.8.7. We have both 1.9.1 and 1.9.3 already installed on slaves so it a matter of figuring out how to run jsduck with the other ruby version :-]
The stacktrace only happened once apparently, not sure it is related to ruby 1.8.x. Since using ruby 1.9 is unlikely to enhance our jsduck run, I am closing this bug.
Ruby 1.8 is past its EOL. We should not be using obsolete software which is no longer receiving bug fixes.
Ruby 1.8 is the default on Precise. And since it is used by puppet among other, I would prefer to stick to it for now :-D
MediaWiki 1.15 is also the default on Precise, you know. The fact that Ubuntu/Debian uses obsolete software doesn't mean we should be using obsolete software. But, well, you're the boss here :)
I've gotten a segfault again. https://gerrit.wikimedia.org/r/#/c/114400/1
(In reply to Bartosz Dziewoński from comment #6) > I've gotten a segfault again. https://gerrit.wikimedia.org/r/#/c/114400/1 https://integration.wikimedia.org/ci/job/mediawiki-core-jsduck/3595/console See https://github.com/senchalabs/jsduck/issues/353. Using upstream recommended workaround as of I1c8dac8dcf537a4a.
The job is still segfaulting. https://gerrit.wikimedia.org/r/#/c/114373/ Was the fix deployed?
Reopening per Timo comment #7. There is a workaround which is to disable parallel processing. Fix is described at https://gerrit.wikimedia.org/r/#/c/114401/ I have refreshed the two jsduck jobs in Jenkins. We will see whether the workaround works.
Thanks to Timo, we now have Ubuntu Trusty instances which comes by default with: $ ruby --version ruby 1.9.3p484 (2013-11-22 revision 43786) [x86_64-linux] $ We can get the JSDuck jobs to run on Trusty node by having them tied to labels UbuntuTrusty && contintLabsSlave then use the jjb push-doc macro to publish to doc.wikimedia.org as described on http://www.mediawiki.org/wiki/Continuous_integration/Documentation_generation
