Teach x-ci-accept-failures to Windows CI tests#28856
Teach x-ci-accept-failures to Windows CI tests#28856shym wants to merge 2 commits intoocaml:masterfrom
x-ci-accept-failures to Windows CI tests#28856Conversation
Handle `"msys2"` and `"cygwin"` values in the `x-ci-accept-failures` field to ignore installation failures on Windows CI, similarly to what is done for other platforms
|
This is excellent - thanks a ton! 🥳 Thinking a bit a head, one could imagine having a "pure-Cygwin" CI workflow too at some future point? 🤔 Note: I am not married to these name proposals ...and I admit having contributed to the existing workflow's naming mess! 😅 |
🙏
There’s indeed quite some name ambiguities, in particular with Cygwin. And I agree it might be sensible to keep
I thought msys2 was always using mingw but now I see an unprefixed Once we settle on names, I suppose the best way to use them would be to assign the |
I believe https://packages.msys2.org/packages/gcc?variant=x86_64 installs an equivalent of Cygwin's That suggests at least two more future CI workflows for 'pure Cygwin' and 'pure MSys2'... 😮
I'm complete fine with changing Polite ping @dra27 and @kit-ty-kate: |
This PR proposes to handle
x-ci-accept-failuresin Windows CI tests just like in other platforms. (This came up in the context of #28750 where it would have helped silence the expected failures.)It uses for that the values
"msys2"and"cygwin": I wondered whether they should be prefixed bywindows(because we usemacos-homebrew, but I supposed that it was because homebrew also exists on Linux, IIUC) and/or suffixed by a version (but I didn’t look whether those are versioned).The second commit is there just to help test the new behaviour and so should be dropped before merging. I hope I covered all the cases with it. In particular it fails intentionally on Cygwin to make sure the failure in one package is not hidden by the other.
(I have little knowledge of powershell syntax so I admit some guesswork has been involved in there…)