Permalink
Browse files

Build on Rubinius and JRuby head again

  • Loading branch information...
1 parent dc04fcd commit 32b2fd7a5b4446243d2d814f24794f9c26354343 @benlangfeld benlangfeld committed Nov 18, 2012
Showing with 2 additions and 6 deletions.
  1. +2 −6 .travis.yml
View
@@ -3,12 +3,8 @@ rvm:
- 1.9.3
- ruby-head
- jruby-19mode
-
-# Getting a deadlock in the nonblocking connect code :(
-# - jruby-head
-
-# See https://github.com/rubinius/rubinius/issues/1611
-# - rbx-19mode
+ - rbx-19mode
+ - jruby-head
notifications:
irc: "irc.freenode.org#celluloid"

5 comments on commit 32b2fd7

These appear to still be failing: https://travis-ci.org/celluloid/celluloid-io/builds/3251259

May I suggest setting them to allow_failures so that we can continue testing them without turning the overall build status red?

Member

benlangfeld replied Nov 21, 2012

If Celluloid tests pass on CRuby but fail on an alternative Ruby implementation, that's a 🐛 in the alternative Ruby implementation, not in Celluloid.

It may be possible to make the tests pass by using a subset of Ruby that is supported by all major implementations. However, this may not be possible, in which case Celluloid's build status is beholden to fixes being applied to JRuby and Rubinius. Then those projects need to 🚢 releases. Then Travis needs to install those releases on its VMs. This whole process can take months.

I assume this is why these lines were commented out by @tarcieri in the first place.

A primary benefit of doing continuous integration testing is to create an awareness of the build status and receive a notification as soon as it changes. With this commit, all builds notifications will be failures for the foreseeable future.

I would like to see these tests passing as much as anybody. I agree it should be a high priority. But you're basically hijacking the build system to prioritize this issue over all other issues, which is not fair.

Owner

tarcieri replied Nov 21, 2012

@sferik there's some legitimate JRuby-specific breakage... possibly in nio4r... possibly in JRuby itself. I haven't isolated it yet. nio4r has its own JRuby specific code and it's possible it could be in error (although I'm the first one who's really tried to exercise some of the nonblocking functionality in JRuby and have reported several bugs).

Until I can track this down and the Celluloid::IO tests are passing on all platforms I'd consider the tests failing, even if things are working on MRI.

@tarcieri Okay. You're the boss.

Please sign in to comment.