CI failures for mingw builds related to Bundler 4

[eregon]

@MSP-Greg Hello, when you have some time could you check these CI failures for mingw?
https://github.com/ruby/setup-ruby/actions/runs/18399031835/job/52423942962?pr=817
https://github.com/ruby/setup-ruby/actions/runs/18399031835/job/52423942981?pr=817

C:\Windows\system32\cmd.exe /D /S /C "D:\ruby-mingw\bin\bundle.bat install --jobs 4"
[REMOVED] Found x64-mingw32 in lockfile, which is no longer supported as of
Bundler 4.0.
Error: The process 'D:\ruby-mingw\bin\bundle.bat' failed with exit code 9

[eregon]

I wonder if it's a Bundler bug, because the lockfile here is generated with bundle lock, so it seems to be Bundler that adds the line it complains about.

[eregon]

I found ruby/rubygems#8733 but not sure what that means

[hsbt]

Thanks to file this.

I'm re-working to develop the next major release from this week with ruby/rubygems#8887.

This may be an issue caused by bumping the major version during the patch picking process.

[MSP-Greg]

@eregon @hsbt

IIRC, the ruby-loco code for ucrt & mingw Ruby is identical except for the compiler setup. Or, they should behave identically. mswin is a bit different, but should still be similar.

The mingw build could be sunset/removed, but I've left it available, as there weren't build problems.

@eregon - in Puma, there were some weird things happening in setup-ruby with truffleruby. I looked at them, and really couldn't see what the cause would be. It is intermittent, see:
https://github.com/puma/puma/actions/runs/18395194985/job/52413125024#step:3:131

I assumed that there were 'other issues' causing these problems, and what @hsbt mentioned indicates that might be. I'll add mingw to Puma's CI, if it has problems, I'll look at maybe adding more tests to ruby-loco. Similar to here, just a GHA step to install gems from a Gemfile.

@hsbt, haven't looked for while, do any of the ruby/ruby CI jobs load from a Gemfile?

[eregon]

@eregon - in Puma, there were some weird things happening in setup-ruby with truffleruby. I looked at them, and really couldn't see what the cause would be. It is intermittent, see:
https://github.com/puma/puma/actions/runs/18395194985/job/52413125024#step:3:131

Right, that's a known issue when Hash is used concurrently. It also happens in TruffleRuby's CI. I plan to fix this soon in TruffleRuby to make Hash thread-safe. It seems more frequent recently, I guess due to more recent Bundler versions.

[MSP-Greg]

@eregon

I plan to fix this soon in TruffleRuby

Thanks for the info. I don't recall if I pinged you, but previously Puma had a several of the non MRI Ruby jobs set to allow test failure.

Problem with that was one had to move to the job's log to see if a failure occurred. So, I switched the 'allow test failure' off. In Puma, sometimes concurrency issues were apparent only with JRuby or TruffleRuby.

A failure in setup-ruby would be visible regardless.