Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Completely overhaul Windows CI #3410

Merged
merged 5 commits into from
Jan 11, 2023
Merged

Completely overhaul Windows CI #3410

merged 5 commits into from
Jan 11, 2023

Conversation

embg
Copy link
Contributor

@embg embg commented Jan 5, 2023

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

  • Upgraded from Visual Studio 2019 to Visual Studio 2022.

Visual Studio + msbuild

  • Deleted Visual Studio 2015 test
  • Kept Visual Studio 2019 test (release build only, to reduce the total number of jobs)
  • Added Visual Studio 2022 test (release + debug)
  • Parameterized the job definition so it can be changed more easily in the future
  • Upgraded the setup-msbuild version from v1.1.3 to v1.3 (future proofing in case v1.1.3 stops working at some point)

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:

  • The mingw-long-test had a build test which was nearly a duplicate of the build test in mingw-short-test. I folded the two build tests together under mingw-short-test, so now mingw-long-test is solely responsible for fuzzing.
  • The PowerShell version of mingw-short-test did not fail the overall job in case the build step failed, due to how errors propagage from sh -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.

@embg embg merged commit 4f7183d into facebook:dev Jan 11, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Visual Studio 2022 testing
3 participants