Test on Windows/Ruby 3.1 with each major childprocess version

[mvz]

Summary

Just testing...

Motivation and Context

Windows + Ruby 3.1 gives test failures: #836. This is is just for investigating.

How Has This Been Tested?

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update
• Internal change (refactoring, test improvements, developer experience or update of dependencies)

Checklist:

• I've added tests for my code
• My change requires a change to the documentation.
• I have updated the documentation accordingly.

[mvz]

🤔 looks like it's broken will all versions of ChildProcess.

[olleolleolle]

@MSP-Greg of Puma has created a set of Windows Ruby build things for Windows. Perhaps those tools can be used, @mvz?

[mvz]

@olleolleolle yeah could be interesting. Do you have a link?

[mvz]

@enkessler are there any known problems with childprocess on Ruby 3.1 on Windows? And/or, has anyone tried running the childprocess test suite on that combination?

[olleolleolle]

https://github.com/ruby/setup-ruby-pkgs

This link mentioned windows-2022 which can be tried, I guess?

[MSP-Greg]

I'll see if I can get childprocess running CI on Actions.

[olleolleolle]

I failed to locate any special tooling in puma/puma, but I linked to this one:

https://github.com/ruby/setup-ruby-pkg

... Which does not seem to match out current needs.

[MSP-Greg]

Windows Ruby 3.1 uses a different Visual C runtime. That may be the cause, I'll see what I can find out. 3.0 uses the same runtime as Rubies 2.4 thru 2.7.

EDIT: Sorry, I just notice the most recent Actions run on main, https://github.com/cucumber/aruba/actions/runs/2357133496. Windows Ruby 3.0 is passing on that run?

[mvz]

Windows Ruby 3.1 uses a different Visual C runtime. That may be the cause, I'll see what I can find out.

Great. Thanks for looking into this.

3.0 uses the same runtime as Rubies 2.4 thru 2.7. Maybe check if the CI runs on Ruby 3.0?

It runs fine on Ruby 3.0. See the github action results for #836.

[mvz]

EDIT: Sorry, I just notice the most recent Actions run on main, https://github.com/cucumber/aruba/actions/runs/2357133496. Windows Ruby 3.0 is passing on that run?

Ha, looks like your edit and my response crossed :-).

[MSP-Greg]

One thing you might try. With the workflow that passes Windows 3.0, add 3.1 and mingw to it. Ruby 3.1 is built with the MSYS2 ucrt tool chain. Ruby 3.0 is built with the mingw tool chain.

But, Ruby head/master builds are available built with both. So, to test against a mingw head build, use 'mingw', to test against a ucrt head build, use ''ucrt'.

So, if the mingw build passes, the issue is related to ucrt builds. If mingw doesn't pass, it may be due to a change from 3.0 to 3.1. I think that made sense...

[MSP-Greg]

@mvz

Thanks for running those. I ran CI in childprocess, and there's a few Windows issues, but ucrt builds have a lot more errors that mingw builds.

Anyway, as your update's run shows, the issue is the API calls in childprocess, some of which must have changed with the update to the newer VC runtime used in the ucrt builds.

There are four Ruby head builds available in Actions. 'ucrt' & 'head' are ucrt builds, 'mingw' is a mingw build, and 'mswin' is built with the Visual C compiler. 'head', 'mingw', and 'ucrt' are built with the MSYS2 ports of gcc...

[MSP-Greg]

ChildProcess needs to find the main Ruby library, and the name of the Windows file changed with Ruby 3.1.

Ruby 3.0 is x64-msvcrt-ruby300.dll, Ruby 3.1 is x64-ucrt-ruby310.dll

See enkessler/childprocess#182

[mvz]

Since childprocess has now been replaced with Process.spawn I'm going to close this. See #892 for details.