mingw.yml - fixup to use ucrt, logging #11015
Conversation
.github/workflows/mingw.yml
Outdated
| mv /c/Windows/System32/libcrypto-1_1-x64.dll /c/Windows/System32/libcrypto-1_1-x64.dll_ | ||
| mv /c/Windows/System32/libssl-1_1-x64.dll /c/Windows/System32/libssl-1_1-x64.dll_ |
There was a problem hiding this comment.
Are these lines needed even after upgrading baseruby to 3.2?
There was a problem hiding this comment.
Removed, and replaced OpenSSL dll's with the new file names in the logging code above.
.github/workflows/mingw.yml
Outdated
| for e in gcc ragel make "openssl version"; do | ||
| case "$e" in *" "*) ;; *) e="$e --version";; esac | ||
| echo ::group::$'\033[93m'$e$'\033[m' | ||
| $e || result=false | ||
| echo ::endgroup:: | ||
| done | ||
| # show packages | ||
| echo ::group::$'\033[93m'Packages$'\033[m' | ||
| pacman -Qs mingw-w64-ucrt-x86_64-* | grep local | sed "s/local\/mingw-w64-ucrt-x86_64-//" |
There was a problem hiding this comment.
| pacman -Qs mingw-w64-ucrt-x86_64-* | grep local | sed "s/local\/mingw-w64-ucrt-x86_64-//" | |
| pacman -Qs mingw-w64-ucrt-x86_64-* | sed "/local/!d;s,local/mingw-w64-ucrt-x86_64-,," |
Or maybe?
| pacman -Qs mingw-w64-ucrt-x86_64-* | grep local | sed "s/local\/mingw-w64-ucrt-x86_64-//" | |
| pacman -Qs mingw-w64-ucrt-x86_64-* | sed -n "s,local/mingw-w64-ucrt-x86_64-,,p" |
There was a problem hiding this comment.
Thanks. Updated code using the 2nd and rebased
|
Like to clarify one thing. In the mingw.yml CI, Currently, the following appears in the step log, which indicates MINGW64 tools/packages are installed, along with OpenSSL 1.1.1:
In the CI after this PR the following appears in the step log, which indicates that UCRT64 tools/packages are installed, along with OpenSSL 3.x:
|
|
A long time ago I decided that if all Ruby Windows CI (not just ruby/ruby, but other repos or gems also) was implementing handling of build tools/packages, it would waste a lot of free resources, and also possibly take longer. So, it was decided to create archive files several times a day and build that into The Since both MSYS2 and MSFT/vcpkg are rolling releases, problems may arise, especially with Ruby stable branches. For example, suppose MSYS2’s current OpenSSL packages was 3.2.1. They then move to OpenSSL 3.3.0. Then a CVE issue arises in 3.2.1, and OpenSSL releases 3.2.2. With a rolling release, 3.2.2 will never be added by MSYS2, as the ‘rolling release’ is already on 3.3.0. So, I’m not sure what the best way to handle stable Ruby branches is. If you want to handle MSYS2 separate from |
The
mingw.ymlworkflow usessetup-rubyto configure/install build tools, packages and the 'baseruby'.setup-rubyis designed to work with most CI, where the tools & packages match the selected Ruby version. Currently, the workflow's selected Ruby version is 3.0.The publicly available Ruby 3.0 is a mingw Ruby that uses OpenSSL 1.1.1. Since we want the head CI to use ucrt tools and packages, and also use OpenSSL 3.3.x, use Ruby 3.2 for the selected/base Ruby.
Additionally, there were two 'informational' steps, combine those into one, and add info as to the current packages installed.
setup-rubycould allow an input to specify the build type and OpenSSL version (defaulting to what the specified Ruby version uses), but there aren't a lot of use cases...