CI failures for mingw builds related to Bundler 4
@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
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.
I found https://github.com/rubygems/rubygems/pull/8733 but not sure what that means
Thanks to file this.
I'm re-working to develop the next major release from this week with https://github.com/rubygems/rubygems/pull/8887.
This may be an issue caused by bumping the major version during the patch picking process.
@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 - 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.
@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.