Skip to content
This repository

Fixing Travis CI #130

Closed
jarl-dk opened this Issue · 13 comments

3 participants

Jarl Friis Matt Wynne Heiko Seebach
Jarl Friis
Collaborator

This is a placeholder for my finding.

  1. I think childprocess is having issues uwing jruby... I will try to isolate the problems and create some demonstrating failing examples in the childprocess project... It will probably take some time.
  2. Travis still fails. Here is some investigation: Travis is using RVM as version manager. If I use RVM I get the same result as Travis (failures) If I use rbenv I don't get any errors in ruby runs of specs and cucumber, and jruby runs of specs also passes, only 11 cucumber tests fails with jruby.

I will try to investigate the difference between RVM and rbenv first
and letting (1) be second priority.

Apparently issue 1 does not occur when using childprocess 0.2.3 and using git bisect shows that jarib/childprocess@5488ed4 is the offending commit.

Jarl Friis
Collaborator

I have fixed (1) by updating to adopt the new behaviour in ChildProcess (this is done in #129). When investigating (2), i.e. why it passed using rbenv, I couldn't reproduce it... Anyway now all the tests passes using MRI via both rbenv and RVM

Left is only a couple of cucumber test (using jruby) that fails... I will investigate on this... But I can't see in (travis build) history that cukes has ever passed using jruby. So I suggest that this is disabled in the jruby on Travis until it has been fixed:

Anyway I can't see how we are going to fix issues like the ones seen on Travis:

$ bundle install
Fetching gem metadata from http://rubygems.org/.........
Installing rake (0.9.2.2)
Installing ffi (1.1.5)
Installing childprocess (0.3.5)
Installing builder (3.1.3)
Installing diff-lcs (1.1.3)
Installing json (1.7.5)
Installing gherkin (2.11.4)
Installing cucumber (1.2.1)
Installing rspec-expectations (2.11.3)
Using aruba (0.5.0) from source at /home/travis/builds/cucumber/aruba
Installing rack (1.4.1)
Installing bcat (0.6.2)
Installing rdiscount (1.6.8) with native extensions
Gem::Installer::ExtensionBuildError: ERROR: Failed to build gem native extension.

 /home/travis/.rvm/rubies/jruby-1.6.8-d19/bin/jruby extconf.rb
WARNING: JRuby does not support native extensions or the `mkmf' library very well.
Check http://kenai.com/projects/jruby/pages/Home for alternatives.
mkmf.rb can't find header files for ruby at /home/travis/.rvm/rubies/jruby-1.6.8-d19/lib/native/include/ruby/ruby.h


Gem files will remain installed in /home/travis/.rvm/gems/jruby-1.6.8-d19/gems/rdiscount-1.6.8 for inspection.
Results logged to /home/travis/.rvm/gems/jruby-1.6.8-d19/gems/rdiscount-1.6.8/ext/gem_make.out
An error occured while installing rdiscount (1.6.8), and Bundler cannot continue.
Make sure that `gem install rdiscount -v '1.6.8'` succeeds before bundling.


install: 'bundle install' returned false.

So we should probably stick to MRI versions of ruby for now...

Jarl Friis
Collaborator

I have marked all scenarios not working (yet) with jruby with @wip-jrupy, and locally everything works fine using bundle exec rake test even using jruby (both via RVM and rbenv). However on Travis there seems to be installiblity problems with jruby, see https://travis-ci.org/#!/cucumber/aruba/jobs/2773121

On jruby in 1.9 mode there are still problems with the rdiscount gem, see https://travis-ci.org/#!/cucumber/aruba/jobs/2773122

Jarl Friis
Collaborator

Now I have updated the .travis.yml to exclude jruby 1.9 mode for now...
Everything should be fine now... But apparently jruby runs differently on Travis than on my computer...

Jarl Friis
Collaborator

OK. I can reproduce the java.lang.ThreadDeath thrown from problem with java 7 (which is used by Travis). I will investigate...

Matt Wynne
Owner

Awesome work @jarl-dk!

Jarl Friis
Collaborator

Thanks, @mattwynne

Jarl Friis
Collaborator

Build status summary

This status is made at this point in time

The following versions works without any errors

  • ruby-1.9.3
  • ruby-1.9.2
  • ruby-1.8.7
  • ree

For jruby I have investigated the following combinations

  1. java: version 6, version 7
  2. jruby: jruby-1.6.8, jruby-1.7.0-rc2
  3. version managers: rbenv, RVM

The boldface is the combination used on Travis.

Combinations

I have examined that status of the build by running these two commands

bundle exec rake

The default rake task both runs all the working scenarios, but also the WIP scenarious in wip mode.

java 6, jruby-1.6.8

On both rbenv and RVM the behaviour is consistent: failing all the scenarios that are marked @wip or @wip-jruby, and passing all others.

java 7, jruby-1.7.0-rc2

On jruby-1.7.0-rc2 (both rbenv and RVM) it is necessary to compile as

JRUBY_OPTS='-Xcext.enabled=true' bundle update

On both rbenv and RVM the behaviour is consistent: failing all the scenarios that are marked @wip or @wip-jruby, and passing all others.

java 7, jruby-1.6.8

This is the combination used by Travis.

Apparantly this combination seem not very stable. All the spec tests
run fine, but it fails sporadically on scenarios that are not marked
@wip or @wip-jruby. Failures includes failures like

Exception: java.lang.ThreadDeath thrown from the UncaughtExceptionHandler in thread "Thread-2"
Exception: java.lang.ThreadDeath thrown from the UncaughtExceptionHandler in thread "Th

Conclussion

To resolve the problems (on Travis) I will investigate the consistent
failures on the combinations java 6, jruby-1.6.8 and java 7,
jruby-1.7.0-rc2. It is much easier to resolve consistent errors than
trying to resolve sporadic errors. That may or may not resolve the
problems on java 7, jruby-1.6.8.

I suggest that you merge this PR (#129) now. And I will continue to investigate the jruby issues.

Jarl Friis
Collaborator

I think we should disable jruby builds from Travis. We need this PR: jarib/childprocess#40 on childprocess to make them work... But that is not enough... There is also an issue in jruby itself... This valid shell line

bundle exec bash -c '(sleep 0; echo "Hello") | ruby -e "puts gets"'

works fine on any MRI ruby and should also work fine on jruby but jruby prints nil. However the almost identical line

bundle exec bash -c '(sleep 4; echo "Hello") | ruby -e "puts gets"'

works fine (though quite slow) on jruby
To work around that jruby bug (or odd behaviour) I will rewrite the aruba tests to use less ruby commands for the interactive tests, but cat...

Jarl Friis
Collaborator

I have filed a bug report on the JRuby project about the above described problem.

Jarl Friis
Collaborator

On jruby:

1) Almost all tests are dependant on childprocess to contain this Pull Request:
jarib/childprocess#41

2) Two cukes ("Running ruby interactively" and "Tons of interactive output" additionally requires either this Pull Request in childprocess jarib/childprocess#40. The PR is merely a workaround for this
bug
which should be fixed in jruby 1.7.1

3) Still even if both of those childprocess pull requests are used, still it sometimes happen that the "Running ruby interactively" fails with an exception like this:

Exception: java.lang.ThreadDeath thrown from the UncaughtExceptionHandler in thread \"Thread-2

It may be because of this bug in JRuby. It has only been seen on a cross between jruby 1.6.8 and JAVA 7.

Jarl Friis
Collaborator

I consider this to be done now, the Travis failures is commented in #129 (comment)

Any comments? @mattwynne ?

Jarl Friis
Collaborator

So travis is happy with #129. Closing this one.

Jarl Friis jarl-dk closed this
Heiko Seebach

Hi,
this sounds somehow familiar to me, see http://jira.codehaus.org/browse/JRUBY-6162
Charles Nutter tried to fix it for 1.7, but moved it to 1.7.1
I also see messages like
Exception: java.lang.ThreadDeath thrown from the UncaughtExceptionHandler in thread "Thread-47"
in various cases but only with JRuby 1.6.8. Wiht 1.6.7.2 I've never seen them.

Matt Wynne mattwynne referenced this issue from a commit
Matt Wynne Revert "They fixed the JRuby bug we found in #130"
This reverts commit be6479c.

Maybe they didn't...? The scenario has failed on JRuby this time. No
time to fix it now so going back to where we were before.
1755125
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.