Use Alpine Linux in WSL on CI

[EliahKagan]

Some of the CI tests use WSL. This switches the WSL distribution from Debian to Alpine, which might be slightly faster. For the way it is being used here, the main expected speed improvement would be to how long the image would take to download*, as Alpine is smaller.

(The reason for this is thus unrelated to the reason for the Alpine docker CI test job added in #1826. There, the goal was to test on a wider variety of systems and environments, and that runs the whole test suite in Alpine. This just changes the WSL distro, used by a few tests on Windows, from Debian to Alpine.)

Two things have changed that, taken together, have unblocked this:

• action failing with a 403 on Alpine etc Vampire/setup-wsl#50 was fixed, so the action we are using is able to install Alpine Linux. See: Bump Vampire/setup-wsl from 3.0.0 to 3.1.0 #1917 (review)

• Some xfail markings fail to validate their exception types #1893 was fixed in lint: add typos check #1888. So if switching the WSL distro from Debian to Alpine breaks any tests, including by making them fail in an unexpected way that raises the wrong exception, we are likely to find out.

---

* Alpine Linux doesn't ship with bash so this has the setup-wsl action install the bash package. Updating package indexes and installing the package in the WSL system adds to the overhead. It is still much faster to set up than Debian... except that obtaining the Alpine Linux image, even though it is smaller than the Debian image, tends to take longer, because it is not available from as fast of a source. This relates to Vampire/setup-wsl#50 (comment); the issue there was about the action not being able to download from the second source at all, which was fixed.

The effect is that Alpine Linux takes longer to download from outside of GitHub, but is faster to retrieve from the GitHub Actions cache and install. Looking at the total time difference added up from all six Windows jobs that use it, this change does slightly better than with Debian. But the slight increase in complexity would likely make it unjustified given the mixed returns. But that's on the feature branch. I believe the cached download will be reusable across separate workflow runs if this is merged, so I would expect a significant overall improvement, with a total time spent getting WSL set up decreased well under half the original total time. So I think it's probably justified.

This is subjective and I will not be sad if you choose to close this without merging.

[Byron]

Thanks a lot being on top of this!

Let's merge and see if we are lucky with compile-time improvements due to effective GitHub CI caching.