bundle install of grpc-1.60.0-x86_64-linux reports that it is incompatible with Ruby 3.3.0 during GitHub CI

[jkwuc89]

What version of gRPC and what language are you using?

grpc-1.60.0-x86_64-linux, Ruby 3.3.0

What operating system (Linux, Windows,...) and version?

ubuntu-22.04-x64 running as part of a GitHub CI

What runtime / compiler are you using (e.g. python version or version of gcc)

Ruby/3.3.0/x64

What did you do?

Please provide either 1) A unit test for reproducing the bug or 2) Specific steps for us to follow to reproduce the bug. If there’s not enough information to debug the problem, gRPC team may close the issue at their discretion. You’re welcome to re-open the issue once you have a reproduction.

Inside Gemfile.lock, I am specifying platform specific versions of grpc as follows:

    grpc (1.60.0-arm64-darwin)
      google-protobuf (~> 3.25)
      googleapis-common-protos-types (~> 1.0)
    grpc (1.60.0-x86_64-darwin)
      google-protobuf (~> 3.25)
      googleapis-common-protos-types (~> 1.0)
    grpc (1.60.0-x86_64-linux)
      google-protobuf (~> 3.25)
      googleapis-common-protos-types (~> 1.0)

The GitHub CI is doing the following.

Modifying PATH
  Entries added to PATH to use selected Ruby:
    /opt/hostedtoolcache/Ruby/3.3.0/x64/bin
Downloading Ruby
  https://github.com/ruby/ruby-builder/releases/download/toolcache/ruby-3.3.0-ubuntu-22.04.tar.gz
  Took   1.16 seconds
Extracting  Ruby
  /usr/bin/tar -xz -C /opt/hostedtoolcache/Ruby/3.3.0 -f /opt/actions-runner/_work/_temp/4ebb1eeb-a07d-4116-940d-65752c05e40a
  Took   0.42 seconds
Print Ruby version
  /opt/hostedtoolcache/Ruby/3.3.0/x64/bin/ruby --version
  ruby 3.3.0 (2023-12-25 revision 5124f9ac75) [x86_64-linux]
  Took   0.02 seconds
Installing Bundler
  Using Bundler 2.5.3 from Gemfile.lock BUNDLED WITH 2.5.3
  /opt/hostedtoolcache/Ruby/3.3.0/x64/bin/gem install bundler -v 2.5.3
  Successfully installed bundler-2.5.3
  1 gem installed
  Took   0.50 seconds
> bundle install
/opt/hostedtoolcache/Ruby/3.3.0/x64/bin/bundle config --local path /opt/actions-runner/_work/core/core/server/vendor/bundle
/opt/hostedtoolcache/Ruby/3.3.0/x64/bin/bundle config --local deployment true
Cache key: setup-ruby-bundler-cache-v6-ubuntu-22.04-x64-ruby-3.3.0-wd-/opt/actions-runner/_work/core/core/server-with--without--only--Gemfile.lock-3ed467be0a4d28dc9639f90f94df51e94e88650d7ccf9da3ee6db851ce5f73ff
Received 163577856 of 1033186910 (15.8%), 156.0 MBs/sec
Received 398458880 of 1033186910 (38.6%), 188.3 MBs/sec
Received 616562688 of 1033186910 (59.7%), 194.8 MBs/sec
Received 830472192 of 1033186910 (80.4%), 197.1 MBs/sec
Cache Size: ~985 MB (1033186910 B)
/usr/bin/tar -xf /opt/actions-runner/_work/_temp/1d1068ed-8b1f-417c-b241-f533342e3aa1/cache.tzst -P -C /opt/actions-runner/_work/core/core --use-compress-program unzstd
Received 1033186910 of 1033186910 (100.0%), 196.2 MBs/sec
Cache restored successfully
Found cache for key: setup-ruby-bundler-cache-v6-ubuntu-22.04-x64-ruby-3.3.0-wd-/opt/actions-runner/_work/core/core/server-with--without--only--Gemfile.lock-7a2fe5006c2bae6b4c6f2fd44e117ed3fcdf43c393476a6cdcb7fc7bd6795c85
/opt/hostedtoolcache/Ruby/3.3.0/x64/bin/bundle install --jobs 4
Fetching gem metadata from https://rubygems.org/.......
Fetching gem metadata from [https://enterprise.contribsys.com/..](https://enterprise.contribsys.com/)
grpc-1.60.0-x86_64-linux requires ruby version < 3.3.dev, >= 2.7, which is
incompatible with the current version, 3.3.0
Error: The process '/opt/hostedtoolcache/Ruby/3.3.0/x64/bin/bundle' failed with exit code 5

What did you expect to see?

bundle install should be able to install and use grpc-1.60.0-x86_64-linux with the released version of Ruby 3.3.0.

What did you see instead?

During bundle install, the following incompatibility is reported:

grpc-1.60.0-x86_64-linux requires ruby version < 3.3.dev, >= 2.7, which is
incompatible with the current version, 3.3.0

See TROUBLESHOOTING.md for how to diagnose problems better.

Anything else we should know about your project / environment?

The app in question is running Rails 7.1.2.

[SybooSyboo782]

https://github.com/radianthero/radianthero.github.io/blob/main/.github/workflows/pages-deploy.yml#L45
해당 경로 참고

[jjf21]

Same problem here:

grpc-1.59.2-x86_64-linux requires ruby version < 3.3.dev, >= 2.7, which is
incompatible with the current version, 3.3.0

any solution ?

[jkwuc89]

Inside my project's Gemfile.lock, we use the following:

    grpc (1.60.0)
      google-protobuf (~> 3.25)
      googleapis-common-protos-types (~> 1.0)

Unfortunately, this can cause a download of the full source code of grpc so that it can be built on the platform where my app is being deployed.

[jeremybdk]

Yes same thing here as it download all the source the gem is close to 1 Gb so we cannot deploy our app 😢

[chadlwilson]

If you don't want to build from source, you need to stay on Ruby 3.2 until grpc relesses a version where the pre-built native extensions declare compatibility with 3.3.

[codykrieger]

+1 — this has added nearly 2GB worth of bloat to our Rails app images and bundler caches on x86_64-linux:

% du -ksh vendor/bundle/3.3.0/gems/grpc-1.60.0/
1.8G	vendor/bundle/3.3.0/gems/grpc-1.60.0/

It seems like the fix for this issue is not working: #33596

The actual shared library is an acceptable size:

% du -ksh grpc-1.60.0/src/ruby/lib/grpc/grpc_c.so
9.1M	grpc-1.60.0/src/ruby/lib/grpc/grpc_c.so

But there's 1.7GB of junk in objs/ and libs/:

% du -ksh grpc-1.60.0/src/ruby/ext/grpc/objs
829M	grpc-1.60.0/src/ruby/ext/grpc/objs
% du -ksh grpc-1.60.0/src/ruby/ext/grpc/libs
944M	grpc-1.60.0/src/ruby/ext/grpc/libs

[codykrieger]

I believe this commit caused the regression from the original fix for #33596: 36af323

hijack: all strip gets prepended to the Makefile above hijack_remove_unused_artifacts: all remove_unused_artifacts, and neither hijack_remove_unused_artifacts nor remove_unused_artifacts are referenced anywhere else, so objs/ and libs/ never get emptied.

[chadlwilson]

The bloat when building from source is probably a separate issue to just actully having prebuilt binaries for 3.3. Maybe best to open a dedicated issue so it isn't lost?

[codykrieger]

@chadlwilson Given the couple other comments complaining about the surprise bloat when building from source, I figured I'd at least add my findings here, but you're probably right. I'll file a separate ticket when I have a minute to fill out the issue template.