Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR overhauls our broken Windows tests (cmake, msbuild, and mingw). Fixes #3064. I'm going to break the summary down into three sections:
Visual Studio + cmake
Visual Studio + msbuild
mingw tests
I spent most of my time unbreaking these tests. It took a lot of trial and error: embg#43
The problem is that GitHub's Windows 2022 image removes some of the msys2 packages that were installed by default in Windows 2019. This is a problem because our mingw jobs were written in PowerShell and replied on certain msys2 packages being installed at certain locations. Using msys2 in GitHub actions from PowerShell is an anti-pattern according to msys2 docs: https://www.msys2.org/docs/ci/
The proper way is to use the
msys2/setup-msys2
GitHub Action to install msys2 and any required packages (such as make and diffutils). I rewrote the mingw jobs to use msys2 properly, fixing the current breakage and preventing future breakages.Some notes:
mingw-long-test
had a build test which was nearly a duplicate of the build test inmingw-short-test
. I folded the two build tests together undermingw-short-test
, so nowmingw-long-test
is solely responsible for fuzzing.mingw-short-test
did not fail the overall job in case the build step failed, due to how errors propagage fromsh -c
to PowerShell. This means the CI job wasn't actually validating the build. I checked that the new setup does fail if the build step fails.