Please run Windows CI in all std-lib repos
Please consider adding Windows CI to all std-lib repos.
Having ruby/ruby CI fail due to std-lib commits merged from their respective repos causes downstream issues, wasted time, etc.
See https://github.com/ruby/irb/pull/179 for an example adding Windows to Actions CI.
Re Actions matrix:
- The os change from
-latestdesignation changes, so some may prefer a
-<numeric>tag. See https://github.com/actions/virtual-environments#available-environments for available environments and their naming.
- Using numeric versions for Ruby causes an issue with 3.0, as it’s interpreted as 3, which is only a sematic major requirement. Hence, quote all numeric versions.
Updated by MSP-Greg (Greg L) 9 months ago
What's mean Windows CI? Is it mingw or mswin or else?
First of all, re ‘or else’,
mingw is widely used, and there are commercial applications using
mswin. Other platforms are much less common.
Everyone is aware of Windows Ruby, so we’ll assume that CI is not done to minimize the number of jobs run. What is adequate CI for Windows? I think it depends on the code being tested.
As to Windows issues, the most common issues are:
- File system path strings, in particular the drive at the root of a path. Note that Windows paths can begin with a
- File system case insensitivity.
- Unavailable features like fork, UNIXSockets, various nonblock operations, etc.
- Compile problems (
mingw’s gcc vs
I’ve been running scheduled
mswin builds at the same time since the introduction of GitHub Actions, and when the code in question is pure Ruby code, both platforms normally fail.
If there were no resource/time constraints, I’d suggest testing on both
mswin. Practically, for Ruby code (not extension code), I think a few
mingw jobs would find the vast majority of compatibility problems.