[ruby] [backport-1.70.x] Build/test ruby 3.4 and build native gems with Ruby 3.4 support (REDUX)#38615
Conversation
To roll forward grpc#38515 As described grpc#38515 (comment), the addition of ruby-3.4 to our cross-compilation matrix caused ruby artifact build times to exceed the 2 hour timeout *on release builds*. For some context around where this was failing, note there are three kokoro jobs that build ruby artifacts: - pull_request `grpc_distribtests_ruby`: runs on 32-core VMs (for presubmit tests) - master branch `grpc_distribtests_ruby`: runs on 32-core VMs (for continuous master branch coverage) - release `grpc_distribtests_ruby`: runs on 16-core VMs (for release builds) Even though all three jobs currently build the *same* set of ruby gems (that is slightly changing with this PR), the release build takes much longer presumably because of the smaller machine type. So even though grpc#38515 was passing during presubmit runs and even on master branch CI, release builds ran into timeouts. So lengthen the timeout for the release builds, which are the slowest. Note our build matrix will shrink again around April when we drop ruby 3.0 (the ruby build matrix is largest between January and April b/c we are adding a new ruby minor version target, but waiting until ~April to delete the new oldest one). Closes grpc#38597 COPYBARA_INTEGRATE_REVIEW=grpc#38597 from apolcyn:bump_ruby_build_timeout b6b3770 PiperOrigin-RevId: 720624102 (cherry picked from commit d45f320)
…t (REDUX) (grpc#38601) Repeat attempt of grpc#38338 to bring Ruby 3.4 precompiled gems to grpc. Pending grpc#38597 Brief history - grpc#38338 merged - grpc#38458 backported to 1.70.x and merged - Above two changes reverted in grpc#38516 and grpc#38515 due to release urgency. Root cause was minor artifact build timeout due to release infra having smaller hosts (fixed in grpc#38597) - Discussion in grpc#38487 about adding back the workaround with `RUBY_PATCHLEVEL`. Unclear if necessary. This PR - cherry-picks the original squashed PR - adds back the `RUBY_PATCHLEVEL` hack, per discussion in grpc#38487 - further upgrades `rake-compiler-dock` to `1.9.1` which avoids coupling patch versions between grpc and rake-compiler-dock - This version changes the host Ruby version from `3.1` -> `3.4` so _technically_ we _could_ validate the theory from grpc#38487. Will await @apolcyn advice. Needs rake-compiler-dock test image re-uploads courtesy of @apolcyn 🙏 Closes grpc#38601 PiperOrigin-RevId: 720824180 (cherry picked from commit ef13727)
|
Will this result in a 1.70.x push to https://rubygems.org/gems/grpc sometime soon? |
Yes, there are a couple more steps to take after merging this, but we want to get this released as 1.70.1 (this week assuming we don't run into more issues). |
Any more issues encountered? |
|
I've just released this in 1.70.1 There was one more snag which is that the So debug symbol packages are missing from 1.70.1, we ought to fix that in either a patch release or the next minor release |
|
Thank you ❤️ 💎 I'm using this gem via Coinbase's Temporal library, https://github.com/coinbase/temporal-ruby. Noticed some slowness on Ruby 3.4. Thanks for all the work you do to precompile binaries for Ruby. |
|
This worked well BeforeGitHub Action w/ Gemfile before AfterGitHub Action w/ Gemfile before 🙏 👏 |
|
@aguynamedben yeah, grpc is a project that takes particularly long to compile extensions on install compared to most ruby gems, so that sounds roughly expected |
Backports #38601 and #38597 to
1.70.x.Equivalent change earlier reverted in #38515 - after which the root cause was traced to a release build timeout due to differing test vs release build infrastructure, which should have been worked around in #38597.
Note that there still appear to be some unrelated Python timeout issues so #38602 or similar may need a merge and backport.
FYI @apolcyn @stanley-cheung