Continuing the theme, add 3 MSVC jobs with tests, matching
configurations used on AppVeyor. MSVC versions are identical:
19.39.33523.0 + Windows SDK 10.0.22621.0.
Also enable websockets, and build examples. Tests are run in parallel
(`-j14`), with improved performance.
Job performance:
```
AppVeyor GHA
w/examples
-------- ----------
CMake, VS2022, Debug, x64, Schannel, Static, Unicode 38m 4s 11m57s
CMake, VS2022, Debug, x64, no SSL, Static 35m15s 12m 6s
CMake, VS2022, Debug, x64, no SSL, Static, HTTP only 25m25s 10m36s
```
Based on these runs:
https://ci.appveyor.com/project/curlorg/curl/builds/49884748https://github.com/curl/curl/actions/runs/9229448468
This is the first time examples are built in CI with MSVC: Fix all
warnings and errors that came up via
d4b8589055#13771.
Closes#13766
Re-implement old mingw-w64 jobs in GHA. This allows to use the latest
Windows runners, replacing Windows Server 2012 R2 (gcc 6) and Windows
Server 2016 (gcc 7, 9) with Windows Server 2022.
GHA runners are also significantly faster, and allow running tests in
parallel (`-j14`). It also offloads 3 more long-running jobs from
AppVeyor CI.
These jobs download (then cache) the mingw-w64 packages from their
original location, which allows flexibility in choosing which versions
and flavours (win32/POSIX, SEH/DWARF, 64/32-bit) we want to test in CI.
The new jobs use these distros:
- https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/ (for gcc 7, same as on AppVeyor)
- https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/ (for gcc 6, same as on AppVeyor)
- https://winlibs.com/ (for gcc 9)
I matched existing AppVeyor job configs, with these differences:
- gcc 6.4.0 instead of 6.3.0.
(same distro as on AppVeyor, but the latest bugfix release)
- gcc 9.5.0 instead of 9.1.0 and a different (but compatible) binary distro.
(in AppVeyor this relies on an old MSYS2 pre-installed on the runner)
- using win32 builds instead of posix for gcc 6.4.0 and 7.3.0.
- websockets enabled.
- always build examples.
- always build tests (this wasn't done for 6.4.0 with AppVeyor CI).
I did not replicate existing test exclusions, and oddly enough the few
failures (so far) were different from MSYS2 jobs and also from their
AppVeyor CI counterparts.
Also:
- delete redundant (default) `-u` option from `cygpath` calls.
- allow matrix options to override default ones in CMake.
- detect and use Windows-supplied curl for `TFLAGS` `-ac` option.
(it's available in modern runners.)
- delete the 3 AppVeyor CI jobs now replicated in GHA.
- appveyor: prefer `SYSTEMROOT` over `WINDIR`.
- tidy-up quotes.
Job performance:
```
AppVeyor GHA
w/examples
w/tests
-------- ----------
CMake, mingw-w64, gcc 6, Debug, x86, Schannel, Static, no-unity 1m25s 8m50s
CMake, mingw-w64, gcc 7, Debug, x64, Schannel, Static, Unicode 31m45s 9m39s
CMake, mingw-w64, gcc 9, Debug, x64, Schannel, Static 28m25s 13m38s
```
Based on these runs:
https://ci.appveyor.com/project/curlorg/curl/builds/49880799https://github.com/curl/curl/actions/runs/9218292508
Notice that building examples and tests is time consuming.
We can tweak any build parameter as necessary to make them more useful
and/or without clogging the job queue or introducing flakiness.
Closes#13759
- re-implement autotools MSYS and Cygwin AppVeyor jobs in GHA.
Now build with SSL and PSL to improve test coverage.
- re-implement MSYS2 mingw-w64 gcc 13 AppVeyor job in GHA.
`CMake, mingw-w64, gcc 13, Debug, x64, Schannel, Static, Unicode`
- add new cmake Cygwin job (build-only).
- enable `-j14` parallelism when running tests.
- delete the 5 migrated jobs from AppVeyor CI.
- add 2 build-only mingw-w64 builds, gcc Release and clang OpenSSL.
- also enable brotli, libssh2, nghttp2 for more test coverage.
These jobs offer better performance, more flexibility and
parallelization compared to the AppVeyor ones they replace. It also
offloads AppVeyor, allowing to iterate faster. They also appear more
reliable than e.g. Azure Windows jobs, where runners are prone to fail
[1].
Closes#13599
[1]:
`Exit code 143 returned from process: file name 'C:\Windows\system32\docker.EXE',
arguments 'exec -i 6b13a669c6dfe7fb9f59414369872fd64d61c7182f880c3d39c135cb4c115c8f
C:\__a\externals\node\bin\node.exe C:\__w\_temp\containerHandlerInvoker.js'.`
