Repository navigation
Windows - ruby-head, ruby-mswin #22
Description
I got the mingw work done in a branch, it was nice to run yarn, yarn run lint, & yarn run package and see only one line changed in dist/index.js. I did update yarn.lock, if that's ok.
Question - should the mswin ruby-version string be 'ruby-mswin'? Obviously, if one is using a single workflow/job layout in Actions, one would need to exclude all OS's except Windows.
It's easy to add, as it's a hard URI, but I'd like to think about whether MSYS2 should be activated or not. I'm thinking not. I'm also wondering whether the 'package action' should be available with it's addition/release. Remember, the main reason I created the build was for stdlib extension gems that are in the Ruby account/organization.
Off topic Windows stuff:
Please see:
https://github.com/MSP-Greg/ruby-setup-ruby/runs/449427016?check_suite_focus=true#step:5:8
I added that line, it shows the gcc version that the Ruby build was compiled with. Note:
(Rev2, Built by MSYS2 project) 9.2.0
Now, in the same step, note line 19:
(Rev2, Built by MSYS2 project) 8.3.0
If you check the most recent action at MSP-Greg/ruby-setup-ruby-info, you'll see that all the recent Ruby binaries were compiled with gcc 9.2.0 Rev 2 (see Ruby info step, ~ line 10 gcc info:). But, the DevKit version, which is shown by 'ridk version' is 8.2.0 Rev 2.
That is the reason I've always had code to update the gcc tools in my Windows actions. But, importantly, updating gcc tools can cause issues with older Ruby binaries, like 2.5.0 or 2.6.0. Long story, it's due adding libssp (Smashing Stack Protector) to gcc in one of the 9.2.0 releases.
Finally, note line 15:
package_version: ruby-loco RI2 2.7.0-1
I modified a file to add the 'ruby-loco', and that is the easiest way to determine where the build came from.
Off topic Actions:
In ruby-loco I have an embedded action that handles the release asset uploading. I prefer to have hard URI, so I set it up as follows:
- Upload replacement build asset with filename 'new_ruby_mingw.7z'
- Delete current asset
- Rename 'new_ruby_mingw.7z' to 'ruby_mingw.7z'
Steps 2 & 3 take around 400 mS. I haven't tried to see what happens during that time period, nor does the GiHub API allow any sort of 'transaction' block...
Activity
eregon commentedon Feb 22, 2020
It's possible to have a fixed URL, without any races with the technique used in https://github.com/ruby/ruby-dev-builder/blob/master/.github/workflows/build.yml
The fixed URL looks like this:
setup-ruby/ruby-builder.js
Line 53 in 94fe020
eregon commentedon Feb 22, 2020
About GCC, doesn't ruby build with the GCC provided in the MSYS2 of GitHub Actions?
Having different versions at build and run time is dangerous, as it might either be incompatible or requires updating at runtime which is quite slow.
eregon commentedon Feb 22, 2020
Ref: ruby/psych#432
MSP-Greg commentedon Feb 22, 2020
Ok. This is messy. Note the info here:
https://github.com/MSP-Greg/github-actions-ruby-info/runs/395672925
If you inspect all the Windows builds, at the top of the 'Ruby Info' step, you'll see 'gcc info:', which is the gcc info from
RbConfig::CONFIG. This is the version of gcc that Ruby was built with. Now, check the 'MSYS2 Package Info' step, and note the 'cc:' info, which is the gcc currently installed in MSYS2.It has always been assumed that the MSYS2 should be updated. I think the default install script for RubyInstaller2 installs automatically prompts one to update MSYS2 at the time of install.
All the recent RI2 builds were built with gcc 9.2.0, but the MSYS2 install contains 8.3.0. Version mismatch.
MSYS, being a package manager, doesn't really have a global version concept, the version info is per package. Since it's a 'rolling' manager, there is no 'normal' way to install a package other than the most current.
In the time I've been using MSYS, this has only been an issue with the newest gcc releases (adding the use of libssp) and OpenSSL, when MSYS2 moved from 1.0.2 to 1.1.1. It's a messy issue, we could handle it in a custom package Action, but it will involve a lot of code. My action handled OpenSSL, but not gcc.
Also, GitHub/MSFT seems to moving along with their own MSYS2 install. For reference, AppVeyor's MSYS2 was updated anytime they did an image update, which was maybe done once a quarter.
Off-topic: When this started (Ruby specific actions), I had two thoughts. First, you are going to learn a lot about Windows & Ruby, and secondly, maybe a Windows specific README document should be added.
eregon commentedon Feb 22, 2020
Right, so the GCC version mismatch seems to be already the case for RubyInstaller2 builds, yet they don't seem to cause much issues in practice.
What about ruby-loco, does it also use gcc 9.2.0 to build?
It seems so: https://github.com/MSP-Greg/ruby-loco/runs/461817634?check_suite_focus=true
Yeah, I am, thanks for all your help there :)
Sounds a good idea if the Windows section in the README becomes too big or we want to expand it quite a bit.
MSP-Greg commentedon Feb 22, 2020
I've already seen issues reported with them locally and maybe in CI. I always use ruby-loco locally, so I don't see any issues unless I'm working with older versions.
It has always built with updates to all packages used. For CI I've helped out with, I've always done the same. Same for ruby/ruby CI. Both actions-ruby and msys-actions perform the update.
I think RI2 does the same, in that any time a Ruby build is created, current MSYS2 packages are used. But, because the assumption that users installing embedded MSYS2 would update their MSYS2 system on install, the embedded MSYS2 was not current.
But, again, a messy side. AppVeyor did not update MSYS2 often. They had a lot of packages installed, so a generic 'full system' update took forever, like an unacceptable amount of time. The messy side is that partial updates may from time to time require special code to update just what one needs. And, the MSYS2 people won't guarantee partial updates always work.
So, on AppVeyor, the ruby-loco build was packaged with a ps1 script that performed the partial update. As to Actions, waiting to see what they do.
Make sense?
eregon commentedon Feb 22, 2020
Makes sense.
Just to understand better, would building ruby-head without updating MSYS2 be possible?
That might be more feasible if GitHub Actions ships a recent-ish MSYS2.
Is building with non-updates packages inadvisable because of security? or other concerns?
MSP-Greg commentedon Feb 22, 2020
Yes. But considering a new MSYS2 won't match that, and a user performing an RI2 install would not have that, why bother? Additionally, ruby-head should be about helping ruby/ruby identify issues (the original reason for ruby-loco), and hence, it should be using the most recent versions of build tools.
Would you recommend using old Ruby, JRuby, or TruffleRuby versions?
Some info/history about MSYS packages. When RI2 and ruby-loco started, we (myself & Lars) were building custom MSYS2 packages for OpenSSL and gdbm. In time, MSYS caught them up. When that happened, I stopped, but Lars continued to build OpenSSL packages, as when MSYS2 updated to 1.1.1, they stopped building 1.0.2 packages.
Installing old MSYS packages cannot be done using standard pacman, but the old packages are available for download. One can download them and install them. So, we could install older versions of anything (including gcc), but we'd have to track all the dependencies, etc...
eregon commentedon Feb 22, 2020
Got it.
I think for CI users of setup-ruby it would be useful if this action just installs Ruby but does not alter the system otherwise more than needed.
If it works reasonably well to use a ruby-head compiled with newer packages on a system with older MSYS2 packages, then it's probably fine. I'm just concerned that we might have to update MSYS2 packages in some cases, and that will probably be slow.
On Linux/macOS, one would use the versions of packages provided by the package manager, very rarely more recent or older. I wish it was as simple as that on Windows, and we could consider whatever is installed in the Windows GitHub Actions image to be enough for building Ruby.
MSP-Greg commentedon Feb 22, 2020
Most people aren't complaining. It seems to take ~ 60 to 90 seconds. That would often be lower if Actions adds an MSYS2 install and keeps it reasonably current.
MSP-Greg commentedon Feb 22, 2020
Sorry I missed it.
Again, messy. If one uses older teeny Ruby versions, updating MSYS2 gcc may cause problems due to the use of libssp. I'm not sure where the 'dividing line' is, I could check it.
MSP-Greg commentedon Feb 22, 2020
In general, I've thought the 'package manager' could have an input that would take a specific string, like
__update__. Using it would perform whatever we considered to be a proper system package update. We might want a string that would never conflict with an existing package name...eregon commentedon Feb 24, 2020
Fixed by #24.