Misc #20523: mswin and MSFT/vcpkg

• Status: Closed
• Assignee: -

[MSP-Greg (Greg L)]

Currently the windows.ymlworkflow caches MSFT/vcpkg packages and the vcpkg.json file locks the vcpkg repo to an older commit. This results in the following package versions being used:

Package          Ruby CI   Current vcpkg
libffi           3.4.4#1     3.4.6
libyaml          0.2.5#4     0.2.5#4
openssl          3.1.1       3.3.0#1
readline         0#4         0#5
readline-win32   na          5.0#8
zlib             1.2.13      1.3.1

Note the updated versions of libffi, openssl, and zlib. There seems to be a concern about using packages from vcpkg’s master branch (see PR #10907). Ruby-loco’s mswin build has been running for almost 5 years, and many of the extension gems that are part of the std-lib use vcpkg master branch packages in their CI. I don’t recall any significant issues with vcpkg.

Depending on the OS, current dependency package versions are often not available. Ruby’s package dependencies are not part of the Windows OS, and MSYS2 and vcpkg normally upgrade packages when they’ve been verified to work with all packages that depend on them.

Hence, Windows CI in Ruby master is an opportunity to check master against the most recent versions of its dependencies.

I would like to propose that either:

1. vcpkg’s commit is updated more frequently to use current package
2. vcpkg master branch is used

[hsbt (Hiroshi SHIBATA)]

• Status changed from Open to Closed

vcpkg’s commit is updated more frequently to use current package

Done, see https://github.com/ruby/ruby/commit/59ab002665cb3c69bdfbf07e73b1a412c5e5205e

vcpkg master branch is used

I don't want to do that. The all of branches are maintained while 3 years. I always spent a lot of time to fix build failure with latest or rolling release packages like Docker image or Linux distribution on old stable branch like ruby_3_1 today.

[MSP-Greg (Greg L)]

@hsbt (Hiroshi SHIBATA)

Thanks for the fix.

When you closed the PR I opened, you stated 'It caused surprisedly build failure with uncontrollable changes by vcpkg repository after 2-3 years.'

I wasn't sure what you were referring to. After seeing your above msg, it's clear you're referring to workflows in Ruby stable/release branches.

I'd prefer to see "builtin-baseline" removed from vcpkg.json in the master branch, and added anytime a stable branch is created.

That would solve your maintenance problem, but allow master to use updated packages without updates to vcpkg.json.

Lastly, locking package versions has a lot of implications regarding CI, especially on Windows where the package systems (MSYS2 & vcpkg) are not part of the OS.

Similar issues have existed with the OpenSSL 1.x vs 3.x problem...

Thanks, Greg