Build failure on JRuby
Closed this issue · 11 comments
It's probably something to do with my dodgy "just use a static fork of the downstreams" strategy.
Looks like #80 had approximately the same failure, so that seems to support that theory.
I'll see what I can see.
Thanks it’s late so I’m off to bed but if we can fix this I’m up to releasing a new version.
Can you point me at the code "just use a static fork of the downstreams" refers to?
Oh, so this isn't a problem with rb-inotify but the tests that are being performed?
Yeah, that's my theory. Especially given #80 had the failure: the only practical difference between the previously green master and that PR was time.
So, this one was passing, but after rerunning it just now, it failed: https://travis-ci.org/guard/rb-inotify/builds/269085800
I wonder if JRuby had a regression of some sort?
cc @headius
Our Travis config specifies an exact JRuby version, so I think that's off the table, even ignoring the unlikelihood.
When I "froze" the other repositories, I failed to note that they don't have a Gemfile.lock -- so we're at the whim of whatever Bundler decides to install based on the current set of published gems. I'll find a coherent set of versions, and see if that helps. We're not here to test other libraries mutual compatibilities -- just that we haven't broken an otherwise known-good combination.
Yeah, that makes sense.
Hmm.. I can't work it out. I had a contemporary clone+lockfile for guard, but that one seems to be [almost] okay anyway.
I didn't have a clone of listen, so I've tried reconstructing a lockfile based on the bundler output from a successful run. But I can't get that one to pass locally: it's showing a bunch of failures no matter what I try. (e.g. I've tried both newer and older versions of JRuby.)
But it's not unique to my point-in-time branch: I'm seeing the same failures on a clean fresh clone of listen master (using released rb-inotify). 😕
The latest version passes on jruby.