-
Notifications
You must be signed in to change notification settings - Fork 145
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix JRuby GitHub Actions workflow #389
Comments
I created a PR for this: https://github.com/honeybadger-io/honeybadger-ruby/pull/390/files However, I dont know enough about Jruby to continue debugging but perhaps this could be a good start for someone else familiar with Jruby + Rails. The error message appears quite nicer |
@ParamagicDev could you try running the Rails 5.2 and 6.0 gemfiles on jruby-9.2.14.0 locally and see if they pass? I suspect they will pass, which would mean something is up with GitHub Actions, I think.
|
I cant even get past I run into an issues with Pry dependencies: WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
Fetching gem metadata from https://rubygems.org/...........
Resolving dependencies.........................................................................................
Bundler found conflicting requirements for the Ruby version:
In rack_1.gemfile:
Ruby
honeybadger was resolved to 4.7.3, which depends on
Ruby (>= 2.3.0)
Bundler could not find compatible versions for gem "pry":
In snapshot (rack_1.gemfile.lock):
pry (= 0.13.1)
In rack_1.gemfile:
pry
guard was resolved to 2.16.2, which depends on
pry (>= 0.9.12)
pry-byebug was resolved to 3.9.0, which depends on
pry (~> 0.13.0)
Running `bundle update` will rebuild your snapshot from scratch, using only
the gems in your Gemfile, which may resolve the conflict. I ran However, I seem to have tracked down the issue we're facing with This seems like a fairly new bug and is probably related to Rails 6 dependency with i18n and with Rails 5.2 And heres the follow up with @headius The same issue is happening with Rails 5.2 but not due to i18n All examples were filtered out; ignoring {:focus=>true} Randomized with seed 22495
...F.....
Failures:
1) Rails integration reports exceptions
Failure/Error: ERB.new(@template ||= File.read(template_file)).result(binding)
NoMethodError:
undefined method `deep_merge!' for {}:Concurrent::Hash
# (erb):51:in `result'
# ./lib/honeybadger/rack/user_feedback.rb:55:in `render_form'
# ./lib/honeybadger/rack/user_feedback.rb:32:in `call'
# ./lib/honeybadger/rack/user_informer.rb:21:in `call'
# ./spec/integration/rails/basic_spec.rb:12:in `block in <main>'
# ./lib/honeybadger/agent.rb:323:in `flush'
# ./spec/integration/rails/basic_spec.rb:11:in `block in <main>' https://github.com/honeybadger-io/honeybadger-ruby/runs/1891102538?check_suite_focus=true |
@ParamagicDev |
Yep, everything Rails 5.2 and Rails 6.0 both pass on jruby-9.2.14.0 locally. So something in the GitHub Actions config or GitHub Actions itself must be causing the failures.
|
Since we're using the latest GitHub Actions Edit: here are quick links: Edit 2: @ParamagicDev your new config makes me think that we may be able to combine the jruby and ruby workflows in the future. |
I can reproduce locally! |
@joshuap yea this can 100% be combined with our current workflow as soon as we get this to pass. |
Success! diff --git a/spec/integration/rails_helper.rb b/spec/integration/rails_helper.rb
index c88d844..c2ee02b 100644
--- a/spec/integration/rails_helper.rb
+++ b/spec/integration/rails_helper.rb
@@ -1,4 +1,8 @@
begin
+ # Require these early to work around jruby/jruby#6547
+ require 'i18n'
+ require 'i18n/backend/simple'
+
require 'rails'
RAILS_PRESENT = true You managed to run into the recently discovered and reported jruby/jruby#6547, an incompatibility between the To be clear, it is a bug in JRuby but was not discovered until this new refinement code landed in i18n. We only found out about it at the beginning of Feb and it will be fixed in the next release of JRuby. The diff above uses a workaround discovered by users. Namely, if you force the refinement to load early, the method is not already there and does not get damaged. Subsequent redefinition of that method works properly. With this change, JRuby 9.2.14.0 should be green on spec:integrations for Rails 6. |
The requires in question do no harm to any other implementation, so they are fine to leave there until you can update test runs to JRuby 9.2.15 or 9.3. We would also like for you to be able to run edge rails... what is the problem there exactly? |
@headius Just ran this in CI. Master rails fails because it requires Ruby version >= 2.7.0 heres the relevant logs: /home/runner/.rubies/jruby-9.2.14.0/bin/bundle lock
Fetching https://github.com/rails/rails.git
Fetching https://github.com/rack/rack.git
Fetching https://github.com/rails/arel.git
Fetching gem metadata from https://rubygems.org/...........
Resolving dependencies........................
Writing lockfile to /home/runner/work/honeybadger-ruby/honeybadger-ruby/gemfiles/rails.gemfile.lock
Cache key: setup-ruby-bundler-cache-v3-ubuntu-18.04-jruby-9.2.14.0-gemfiles/rails.gemfile.lock-c0c57b5eed6e2399faa599f2aa036d8caaee1943a63dff72d6e0587444087d3a
/home/runner/.rubies/jruby-9.2.14.0/bin/bundle install --jobs 4
Fetching gem metadata from https://rubygems.org/..........
activesupport-7.0.0.alpha requires ruby version >= 2.7.0, which is incompatible
with the current version, ruby 2.5.7p0 (jruby 9.2.14.0) And link to CI run. https://github.com/honeybadger-io/honeybadger-ruby/pull/391/checks?check_run_id=1895718268 |
@ParamagicDev Ahh well that is a bit trickier to fake. It is probably fine, though... JRuby 9.3 will support Ruby 2.6 features (release in next month or so) and the next major release will go straight to 3.0. We should be able to support Rails 7 long before it is out. FWIW I doubt Rails is using anything from 2.7 that wasn't in 2.6. There simply weren't that many features added. Thanks for the update! |
The JRuby GitHub Actions workflow is currently on a branch, and currently failing.
See comment by Charles here for ideas.
The text was updated successfully, but these errors were encountered: