You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
CI failures for mingw builds related to Bundler 4 #818
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.
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.
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?
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.
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.
Activity
eregon commentedon Oct 10, 2025
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 commentedon Oct 10, 2025
I found ruby/rubygems#8733 but not sure what that means
hsbt commentedon Oct 10, 2025
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 commentedon Oct 10, 2025
@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:
http://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 commentedon Oct 10, 2025
Right, that's a known issue when
Hashis 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 commentedon Oct 10, 2025
@eregon
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.