Bundler is broken under jruby-9.2.14.0 on Windows

[slonopotamus]

See https://github.com/ruby/setup-ruby/runs/1542522363#step:3:25

Other projects also hit this: https://github.com/slonopotamus/asciimath/runs/1545553883?check_suite_focus=true#step:4:10

Possibly you want to revert 0981b5e until this is fixed.

[eregon]

See #128 and rubygems/rubygems#4129
It's not about JRuby 9.2.14.0 vs 9.2.13 but about Bundler 2.2.0 + a bug in all JRuby 9.2 releases so far.

[slonopotamus]

Well, my point is that it's setup-ruby who decides what exact Bundler version and what exact JRuby version to install when user requests jruby.

[slonopotamus]

You already have logic like "install bundler 1.x on JRuby 9.1". Maybe you could also help users with current issue the same way?

[eregon]

Well, my point is that it's setup-ruby who decides what exact Bundler version and what exact JRuby version to install when user requests jruby.

No, it's RubyGems. setup-ruby only does gem install bundler -v '~> 2'.
I'm not going to compensate and add extra complexity for upstream bugs like that which need to be addressed upstream.

That 9.1 case is only because Bundler 1 seems unmaintained, and because there is a similar case for CRuby 2.3, i.e., there is no other possible fix.

[slonopotamus]

I'm not going to compensate and add extra complexity for upstream bugs like that which need to be addressed upstream.

Okay, that's why I initially suggested to just skip broken JRuby version.

[eregon]

Okay, that's why I initially suggested to just skip broken JRuby version.

It also fails on JRuby 9.2.13.0 + Bundler 2.2.0, as I said above (so that wouldn't help).
Take a look at the linked issue for more details.

Anyway, you can workaround with:

    - uses: ruby/setup-ruby@v1
      with:
        ruby-version: ...
        bundler: 2.1.4

[slonopotamus]

Uh. I just hoped to fix it in a single place (setup-ruby) instead of having to walk twice through all workflows that run jruby+windows. First to add a workaround and then to remove it back when a fixed JRuby version is released.

[eregon]

So I think the only thing ruby/setup-ruby could do to workaround this (to be clear in no case this can be considered a ruby/setup-ruby bug) would be to pick Bundler 2.1.4 when bundler: 2 (or the default) is specified.

But that's inevitably going to be confusing for users which expect latest Bundler, and then rubygems/rubygems#3256 would be an issue again.

Maybe using Bundler 1 is more compatible with JRuby 9.2 on Windows?

[slonopotamus]

to be clear in no case this can be considered a ruby/setup-ruby bug

Yeah, I fully agree it's not setup-ruby fault.

But that's inevitably going to be confusing for users which expect latest Bundler, and then rubygems/rubygems#3256 would be an issue again.

rubygems/rubygems#3256 is workaroundable in a way that doesn't need to be reverted later. Also, rubygems/rubygems#3256 was broken for such a long time that most likely people already made a workaround for it in their workflow files.

[eregon]

@deivid-rodriguez What do you think regarding my comment just above?

Should we workaround in ruby/setup-ruby for Bundler 2.2.0-related issues by picking 2.1.4 instead until there is a new release fixing those issues (rubygems/rubygems#4123, rubygems/rubygems#4129) ? (the second one potentially needing a JRuby release)

I can see it's useless to fail all workflows if e.g. Bundler 2.2.0 didn't work at all, but this is not the case, it's only some combinations that fail and in fact with rubygems/rubygems#3256 we have an example of not using Bundler 2.2.0 causing another bug.
Also, since some workflows already use Bundler 2.2.0, we might have some subtle issues if they suddenly use Bundler 2.1.4 again.

Honestly, I'm happy to care about ruby/setup-ruby bugs, but not about potentially any bug in some Ruby implementation and/or in RubyGems/Bundler, that just feels out of scope.

[slonopotamus]

Honestly, I'm happy to care about ruby/setup-ruby bugs, but not about potentially any bug in some Ruby implementation and/or in RubyGems/Bundler, that just feels out of scope.

Well, setup-ruby own test CI doesn't pass currently. Is it going to be fixed somehow or it will be left in this state until one of (JRuby|Bundler) fixes the issue?

[eregon]

Another concern is, if a bug is annoying, then people should make that clear on the upstream ticket, to clarify a release fixing it is warranted.
Working around it here won't solve it for actual non-CI users, so the only real fix is upstream fixes anyway, and I think it's more useful to push for that than for workarounds which would only apply for ruby/setup-ruby, but still be issues for actual non-CI users.

What I don't appreciate about this issue report is I get all the work and trouble, when it's in no case my fault.

Well, setup-ruby own test CI doesn't pass currently. Is it going to be fixed somehow or it will be left in this state until one of (JRuby|Bundler) fixes the issue?

Current plan is waiting for an upstream fix, yes. I feel I already did more than my part by reporting the bug upstream.
Having to do two releases + changes in setup-ruby + having to follow about it to workaround that seems heavy.

Anyway, it's Sunday, so I won't look at this ticket anymore today.

[deivid-rodriguez]

I plan to release 2.2.1 with a bunch of fixes hopefully tomorrow. I know it's annoying and I apologize for the issues, I don't think ruby/setup-ruby should take any action here.

You have already provided two ways for people to lock their version of bundler through either an exact version, or using bundler: Gemfile.lock so if people really want their CIs to be deterministic and independent from third party dependency changes, they should use those tools you are providing. I fully recommend the bundler: Gemfile.lock setting and plan to make that the default behaviour of bundler in the future.

[deivid-rodriguez]

Amen @eregon, this is not your fault, you've done more than enough.

[slonopotamus]

if a bug is annoying, then people should make that clear on the upstream ticket, to clarify a release fixing it is warranted.

Good idea, will complain there.

Current plan is waiting for an upstream fix, yes. I feel I already did more than my part by reporting the bug upstream.

Understood.

Anyway, it's Sunday, so I won't look at this ticket anymore today.

I got your point, I don't think there's any need to discuss anything more here.

Thanks for a quick response and all the great work you do!

[headius]

@eregon I understand it is frustrating that an upstream bug indirectly impacted setup-ruby users, but I don't think it is reasonable to force those users to upgrade their JRuby apps just to keep using the setup tool.

As I pointed out in the RubyGems issue, a JRuby release will happen (at the earliest) in January... but it will not help users of JRuby 9.2.14.0 and earlier.

I plan to release 2.2.1 with a bunch of fixes hopefully tomorrow.

@deivid-rodriguez Thank you!

The Bundler 2.1.4 workaround suggested by @eregon is fine for the (very) short term, but a quick Bundler 2.2.1 release would solve the issue for all users on all affected JRuby versions. I believe it would also be picked up automatically by setup-ruby, requiring no additional work on @eregon's part.

[headius]

I don't think it is reasonable to force those users to upgrade their JRuby apps just to keep using the setup tool.

@eregon I should clarify that I don't think this situation is setup-ruby's fault and I appreciate your filing the Bundler issue. Assuming Bundler 2.2.1 gets picked up automatically, there probably isn't anything else you need to do.

[deivid-rodriguez]

I believe it would also be picked up automatically by setup-ruby, requiring no additional work on @eregon's part.

This is now users choice, they can also lock to a known working version with bundler: Gemfile.lock. But the default is still bundler: latest, so users affected by this that didn't take any action yet will get this automagically fixed when we release bundler 2.2.1.

[eregon]

FYI, the default of the bundler: input is to use the Gemfile.lock / lockfile if there is one, and otherwise the latest Bundler:

setup-ruby/action.yml

Line 16 in a992698

Defaults to 'Gemfile.lock' if the file exists and 'latest' otherwise.

We can see bundler as a gem, and the way to deal with issues in other gems is to pin the version, so I think pinning the Bundler version is something sensible if someone wants to avoid any change there. And this would automatically happen if one has a checked-in Gemfile.lock, but that's not always the case, especially for testing gems.

[deivid-rodriguez]

Oh nice, I missed that! I like your default 👍.