Note that the file vcpkg.json was added to the repo, but the workflow was never updated to work with it. So, it only works with a local installation when used properly.

Tried to install using manifest mode.
463ebb8
This takes 20min to install packages.

When one switches to 'manifest' mode, at least one of the vcpkg caches should be moved, as the packages are installed in the same folder as the json file. That may be part of the problem.

For GHA, an archive file (7z?) is generated once a day from vcpkg master. That could be used, but that's a 'rolling release'.

All of the default and bundled gems that test with mswin use it.

There's two issues here...

1. Should the repo lock library package versions?

2. Fix the CI.

Re the first issue, I think Ruby head should use the most current library packages available. I believe both MSYS2 and MSFT/vcpkg recommend that.

This takes 20min to install packages.

Without the cache, that's probably a full build.

@nobu

The code behind setup-ruby and its installation of WIndow's build tools/packages seems to be reliable. The only recent issue I can recall is when MSYS2 decided to split a package into two packages, a dev and runtime, similar to some packages on *nix systems.

So, I replaced the vcpkg code here with code to download the mswin package files. The commit is here and the Actions run is here. It is using the same archive file for all jobs, it's compiled with VS 2022.

Any thoughts? It's quite a bit quicker.

I don't want to upgrade with rolling releases like homebrwe, vcpkg. It's fragile on old branches like ruby_3_1.

I'm okay to use manifest mode with builtin-baseline.

@hsbt

You mentioned Homebrew & vcpkg, MSYS2 is also a rolling release.

These two PRs for Windows workflows are for master branch. Are you ok with using rolling releases for master? 'stable' branches are another issue.

An issue with some of the workflows is that some cache keys are not job specific. Or, if workflow changes are backported, a master cache could be incorrectly used on a stable branch job.

In the 'bug tracker' you mentioned a problem. Do you recall the exact details? Both of the PRs add code to list dependent package versions.

Also, re 3.1 mingw, it is using an incorrect base Ruby, which loads ucrt tools with OpenSSL 3. I think I have a patch for the mingw workflow, haven't looked at the mswin. I haven't looked at the 3.2 or 3.3 workflows.

These two PRs for Windows workflows are for master branch. Are you ok with using rolling releases for master? 'stable' branches are another issue.

No. master will become stable branch every year.

I know you work to support mswin and mingw platform. Thank you for that.

But It's your work, not me. I spent a lot of time to keep stable status for ruby_3_1 like:

• Fix build error with old OS distributions like CentOS7 and Amazon Linux 2 #10840
• Fix build failure of OpenBSD #10838
• [Bug 20151] Fix build failure of FreeBSD 14.x #10814
• Skip tests related OpenSSL #10784
• Fix CI failure for Ruby 3.1 #10512
• Fix test-bundled-gems for Ruby 3.1 #7935
• Re-enable example for Europe/Amsterdam pre-1970 time for Ruby 3.1 #6468

The above PR is all for differences with old branch and modern platform(or too old platform). I don't wont to expand these differences for mswin platform.