Adding ruby ubuntu ppc64le/s390x binaries on ruby/ruby-builder releases

[junaruga]

This topic is about ruby/ruby-builder. However, as there is no issues feature in the ruby/ruby-builder repository, I think this ruby/setup-ruby using the ruby/ruby-builder is suitable for this topic.

The topic comes from https://github.com/IBM/actionspz/issues/4#issuecomment-3498761835.

@dale-fu at GitHub Actions ppc64le/s390x project contacted me at https://github.com/IBM/actionspz/issues/4#issuecomment-3498761835. The request is maybe they want us to add the the ppc64le/s390x ruby version binaries to the ruby/ruby-build repository releases to be used in their GitHub Actions ppc64le/s390x, as well as GitHub Actions x86_64/arm64.

I discussed with @eregon about a similar topic in the past in the conversation https://github.com/ruby/fiddle/pull/191#discussion_r2361052468. At that time, we concluded the ruby/setup-ruby (and ruby/ruby-builder) would only support the binaries provided by GitHub hosted runners (x86_64, arm64), and would not support the self hosted runners (ppc64le, s390x) because we wanted to save the time to create our supported Ruby version binaries.

@eregon I want to discuss about the ppc64le/s390x support again. I think at least we can try to test how the running time to create the ruby binaries is when adding the ruby ubuntu ppc64le/s390x binaries if your concern is a longer running time to create the ruby binaries. What do you think?

@dale-fu If you have something to add, please write. Your request is only for ruby/ruby-builder? The ruby/setup-ruby is optional?

[dale-fu]

Thanks for opening the issue for us. As our team has recently launched the GitHub Actions runners on IBM platforms, we try to keep as many packages/tools in parity with the official actions runners. To reiterate our intentions, we are aware that the official runners have additional Ruby versions installed via the ruby/ruby-builder repo, so we were wondering if your team would be open to building binaries on s390x/ppc64le. We would also love to have additional Ruby version installed on our IBM runners for the community to use. Currently on our s390x/ppc64le runners, we only have Ruby installed via apt.

[junaruga]

@eregon I am waiting for your response. I plan to open a PR to the ruby/ruby-builder repository, adding the ubuntu ppc64le/s390x ruby cases, and measure the running time of the CI for us to check if the running time is realistic or not.

[eregon]

I think a good starting point would be a PR to https://github.com/ruby/ruby-builder building a single release (e.g. 3.4.7) on these new platforms. And we can see whether that works or not and how much is involved to get the builds. To try a build you can probably trigger a build in your fork of that repo, I let you figure that out.

One requirement from my side is that this requires minimal time from me. Part of it is I think these platforms/archs are pretty niche and so the effort should be proportional to how much use they see (very little compared to AMD64/AARCH64).

[eregon]

To try a build you can probably trigger a build in your fork of that repo, I let you figure that out.

Ah but that will probably not work because those runners are only available to the ruby org repos? That's a pretty bad sign to me, and it confirms in general that setup-ruby & related repos should never use any self-hosted runners, only free GitHub-hosted runners available for everyone. There are many reasons including:

• The CI should be able to be run by anyone, in their fork too.
• There are many security considerations with self-hosted runners and it feels too unsafe to run ruby-builder there, e.g. it could compromise builds on other platforms. As one example I don't even see the repo defining how these IBM images are built.
• Whenever there is an issue it would force people with write access to this repo & ruby-builder (basically me) to deal with it vs making it possible for other people to help too.

Back to my points in https://github.com/ruby/fiddle/pull/191#discussion_r2360917883 basically. And more reasons to not do any builds on self-hosted runners at https://github.com/ruby/setup-ruby/issues/600#issuecomment-2139548389

[eregon]

So one way here is the IBM team forks ruby-builder and runs builds for those platforms on their fork. Then there is no overhead here and much fewer security concerns.

ruby/setup-ruby could be used as-is for Ruby versions preinstalled in the runner tool cache.

[eregon]

Maybe we need to clarify the goals here:

• Re having more versions the toolcache as mentioned in https://github.com/IBM/actionspz/issues/4#issuecomment-3498761835, the simplest would be to tweak the code to create the runner-images code to build some Ruby versions. This is what GitHub-hosted runners used to do before ruby-builder. I suppose for Python and other things in the toolcache it's already done that way? BTW https://github.com/actions/python-versions/releases does not contain ppc64le/s390x binaries and I'd guess they won't in the future either.
• If it's for more convenient testing of ruby/ruby, extra Ruby binaries are unnecessary.
• If it's for more convenient testing of ruby/*, then it would need full setup-ruby support.
• If it's for more convenient testing of gems on these platforms, then ppc64le/s390x runners should become GH-hosted runners or equivalent available to everyone.

Basically I'm uncomfortable with this status in between of ppc64le/s390x runners not being globally available, so very few people can use it, and then doing extra work just for that. IOW, if it's mostly to have extra Ruby versions in the toolcache, then I think it makes more sense for the ppc64le/s390x images maintainers to take care of that.

[junaruga]

Thanks for your comments!

Ah but that will probably not work because those runners are only available to the ruby org repos?

These runners are only available to the registered repositories including ruby/* repositories. People can register their repositories by the https://github.com/IBM/actionspz/issues. But I don't think not every project is approved to use the GitHub Actions ppc64le/s390x. I assume this strategy choice is to manage the cost of the servers used for GitHub Actions ppc64le/s390x.

And more reasons to not do any builds on self-hosted runners at https://github.com/ruby/setup-ruby/issues/600#issuecomment-2139548389

I will read and understand your concerns written on the above link.

Re having more versions the toolcache as mentioned in https://github.com/IBM/actionspz/issues/4#issuecomment-3498761835, the simplest would be to tweak the code to create the runner-images code to build some Ruby versions. This is what GitHub-hosted runners used to do before ruby-builder. I suppose for Python and other things in the toolcache it's already done that way? BTW https://github.com/actions/python-versions/releases does not contain ppc64le/s390x binaries and I'd guess they won't in the future either.

This looks a realistic choice.

[junaruga]

And more reasons to not do any builds on self-hosted runners at https://github.com/ruby/setup-ruby/issues/600#issuecomment-2139548389

I will read and understand your concerns written on the above link.

You have 3 concerns on the linked comment.

What if those custom Windows ARM runners are running a different Windows version vs what other users use? Or what if those runners have some software installed/configured differently which means it works there but not in other places? For example the current windows toolchain stuff does need to assume things about where git and openssl and MSYS2 packages are installed and which versions, etc.

These runners might have a different CPU, and some of the compilation might be CPU-features specific.

The 1st and 3rd concerns are also the case of the x86_64, aren't they?

If the builds are done on these runners (would be a concern for https://github.com/oneclick/rubyinstaller2/issues/362 I'd think and for building the windows toolchain stuff), there is a security concern that anything compromised on these runners (e.g. a bad gcc installed by some virus) could end up in the resulting CRuby build, which could result in affecting any user of these builds.

I think this security risk on runners can happen in both GitHub hosting CI and self hosting CI runners, right?

[junaruga]

Re having more versions the toolcache as mentioned in https://github.com/IBM/actionspz/issues/4#issuecomment-3498761835, the simplest would be to tweak the code to create the runner-images code to build some Ruby versions. This is what GitHub-hosted runners used to do before ruby-builder. I suppose for Python and other things in the toolcache it's already done that way?

@dale-fu I think a realistic way is to tweak the code to build some Ruby versions from the sources to create the ppc64le/s390x runner-images shipping the Ruby version binaries. what do you think? Are you familiar with the Python and other programming language's cases to ship the version ppc64le/s390x binaries?

[eregon]

The 1st and 3rd concerns are also the case of the x86_64, aren't they?

Yes, but we don't use self-hosted runners for any builds. So we only have to trust GitHub and the images they provide, which people must trust anyway since they also use those images. Also AFAIK the code to create these images is entirely OSS.

[junaruga]

So we only have to trust GitHub and the images they provide, which people must trust anyway since they also use those images. Also AFAIK the code to create these images is entirely OSS.

OK. This is related to your above 2nd concern. Yes, I understand that. This is to minimize the risk of the supply (tool) chain attack. We want to separate the tool chain provided by the company GitHub (GitHub hosted runner) from the tool chain provided by the 3rd-parties (self hosted runner).