Add JRuby 9.2 to the test matrix

[pkuczynski]

No description provided.

[rdubya]

I think the changes are ok, but it looks like travis is using too old of a version of rvm so it isn't recognizing some of them

[rdubya]

Would it make things easier if we pulled the bundler dependency out of the gemspec so we aren't forcing a specific version of bundler?

[pkuczynski]

Yeah, good idea!

[rdubya]

I realized the JRuby specs will fail because sqlite3 isn't compatible with jruby, we need to conditionally include activerecord-jdbcsqlite3-adapter in that case.

[pkuczynski]

Do you wanna update this PR? Ideally, we should get rid of ActiveRecord dependency. It doesn't really make sense for this gem, don't you think?

All we rely on is active_support/core_ext/module/attribute_accessors - can this be easily replaced by something else?

[pkuczynski]

If I understand correctly https://stackoverflow.com/questions/185573/what-is-mattr-accessor-in-a-rails-module the attribute_accessors are only needed to provide mattr_accessor, so maybe we can just replace it with explicit setters/getters definition? What do you think?

[pkuczynski]

@eregon seems that your jruby is built without or with wrong libyaml: https://github.com/rubyconfig/config/pull/228/checks?check_run_id=380015086

Can you help?

[eregon]

It looks like a bug of JRuby when running in GitHub Actions.
Not sure what's causing it.
I found this issue: rubygems/bundler#6878 (comment)
But it would good to file a new issue at https://github.com/jruby/jruby

[eregon]

JRuby is not using libyaml AFAIK, they have their own version of SnakeYAML AFAIK.

[pkuczynski]

Hmm, JRuby seems to be very flaky. Worked for 8ae80e9 and failed for 74b650f

This is really strange...

[eregon]

I filed jruby/jruby#6023

[headius]

Hmm, JRuby seems to be very flaky.

I assume you mean JRuby support on Github actions is flaky. If JRuby works once it should work every time. I strongly suspect there's some change in the Github actions environment that's messing with how we locate the Psych library, like it's picking up a GEM_HOME pointing at CRuby gems.

[headius]

Also confirming @eregon's statement: JRuby does not use libyaml; we use SnakeYAML, which is shipped in-the-box with our psych extension as part of the JRuby distribution.

Literally any system with a working JDK should be able to run JRuby from that tarball with no additional dependencies or build steps. This is an environment issue.

[pkuczynski]

@headius yeah, that's what I mean :)

I also posted an example on jruby/jruby#6023

If you have any suggestions how can we get this build working, I am very keen to hear about it! Maybe it's connected with the gem cache from GHA?

[headius]

Maybe it's connected with the gem cache from GHA?

I think you nailed it. I just noticed that the failed build was able to restore a cache and the successful one was not. I suspect it's assuming the CRuby cached gems are ok for JRuby and loading the CRuby psych somewhere in the pipeline.

[pkuczynski]

That's odd as I include jruby in my cache key, so it should be only relevant to jruby...

[headius]

See also rubygems/bundler#6878 (comment) where @enebo describes a very similar problem. In that case, the wrong version of SnakeYAML was getting picked up, which causes Psych to fail rather far along in its boot process because of an incompatible SnakeYAML API.

Edit: wrong link

[pkuczynski]

@headius it can not be a cache issue. Now the build had no-cache (I intentionally changed the key to test it) and it still failed the same way: https://github.com/rubyconfig/config/runs/380132707

[headius]

@pkuczynski See jruby/jruby#6023 (comment)

This is a horrible thing to have set in a default CLASSPATH. GHA needs to remove that. For now I'd suggest clearing that var.

[pkuczynski]

Waiting for actions/runner-images#242 to be solved