[ruby] bump ruby artifact build timeout#38597
Closed
apolcyn wants to merge 1 commit intogrpc:masterfrom
Closed
Conversation
Contributor
|
Thx for the context! |
|
Is the failing #38602 ? |
"Basic Tests Python Windows" - but there is another PR for python failing (#38602 ) |
veblush
approved these changes
Jan 28, 2025
copybara-service bot
pushed a commit
that referenced
this pull request
Jan 29, 2025
…t (REDUX) (#38601) Repeat attempt of #38338 to bring Ruby 3.4 precompiled gems to grpc. Pending #38597 Brief history - #38338 merged - #38458 backported to 1.70.x and merged - Above two changes reverted in #38516 and #38515 due to release urgency. Root cause was minor artifact build timeout due to release infra having smaller hosts (fixed in #38597) - Discussion in #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 #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 #38487. Will await @apolcyn advice. Needs rake-compiler-dock test image re-uploads courtesy of @apolcyn 🙏 Closes #38601 PiperOrigin-RevId: 720824180
chadlwilson
pushed a commit
to chadlwilson/grpc
that referenced
this pull request
Jan 29, 2025
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)
chadlwilson
added a commit
to chadlwilson/grpc
that referenced
this pull request
Jan 29, 2025
…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)
apolcyn
added a commit
that referenced
this pull request
Jan 29, 2025
…th Ruby 3.4 support (REDUX) (#38615) 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 --------- Co-authored-by: apolcyn <apolcyn@google.com>
paulosjca
pushed a commit
to paulosjca/grpc
that referenced
this pull request
Feb 20, 2025
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
paulosjca
pushed a commit
to paulosjca/grpc
that referenced
this pull request
Feb 20, 2025
…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
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
To roll forward #38515
As described #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:
grpc_distribtests_ruby: runs on 32-core VMs (for presubmit tests)grpc_distribtests_ruby: runs on 32-core VMs (for continuous master branch coverage)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 #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).