Ruby 3.3.6 isn't being cached consistently

Hello, I’m having some issues with the build on my site, giventotri. I recently updated it to Ruby 3.3.6, and I’m noticing that apparently every other build (the site builds itself once an hour), Ruby is downloaded, built, and installed from scratch instead of installing from cache, which adds minutes to the build.

For example, this build installed Ruby from cache, as expected, and took 1:18 in total, with the Ruby installation being virtually instantaneous:

5:01:26 AM: Required ruby-3.3.6 is not installed.
5:01:26 AM: To install do: 'rvm install "ruby-3.3.6"'
5:01:26 AM: Attempting Ruby version 3.3.6, read from .ruby-version file
5:01:26 AM: Started restoring cached Ruby version
5:01:26 AM: Finished restoring cached Ruby version
5:01:27 AM: Using Ruby version 3.3.6

An hour later, the next build installed Ruby from scratch, and the build took over four minutes, with half of that time spent just installing Ruby:

6:01:35 AM: Required ruby-3.3.6 is not installed.
6:01:35 AM: To install do: 'rvm install "ruby-3.3.6"'
6:01:35 AM: Attempting Ruby version 3.3.6, read from .ruby-version file
6:01:35 AM: Required ruby-3.3.6 is not installed - installing.
6:01:35 AM: Searching for binary rubies, this might take some time.
6:01:38 AM: No binary rubies available for: ubuntu/20.04/x86_64/ruby-3.3.6.
6:01:38 AM: Continuing with compilation. Please read 'rvm help mount' to get more information on binary rubies.
6:01:38 AM: Checking requirements for ubuntu.
6:01:38 AM: Requirements installation successful.
6:01:38 AM: Installing Ruby from source to: /opt/buildhome/.rvm/rubies/ruby-3.3.6, this may take a while depending on your cpu(s)...
6:01:38 AM: ruby-3.3.6 - #downloading ruby-3.3.6, this may take a while depending on your connection...
6:01:38 AM: No checksum for downloaded archive, recording checksum in user configuration.
6:01:39 AM: ruby-3.3.6 - #extracting ruby-3.3.6 to /opt/buildhome/.rvm/src/ruby-3.3.6.....
6:02:04 AM: ruby-3.3.6 - #configuring...................................................................
6:02:04 AM: ruby-3.3.6 - #post-configuration..
6:03:27 AM: ruby-3.3.6 - #compiling........................................................................................................
6:03:30 AM: ruby-3.3.6 - #installing......................
6:03:30 AM: ruby-3.3.6 - #making binaries executable...
6:03:31 AM: Installed rubygems 3.5.22 is newer than 3.0.9 provided with installed ruby, skipping installation, use --force to force installation.
6:03:31 AM: ruby-3.3.6 - #gemset created /opt/buildhome/.rvm/gems/ruby-3.3.6@global
6:03:32 AM: ruby-3.3.6 - #importing gemset /opt/buildhome/.rvm/gemsets/global.gems......................................................................
6:03:33 AM: ruby-3.3.6 - #generating global wrappers........
6:03:33 AM: ruby-3.3.6 - #gemset created /opt/buildhome/.rvm/gems/ruby-3.3.6
6:03:33 AM: ruby-3.3.6 - #importing gemsetfile /opt/buildhome/.rvm/gemsets/default.gems evaluated to empty gem list
6:03:33 AM: ruby-3.3.6 - #generating default wrappers........
6:03:33 AM: ruby-3.3.6 - #adjusting #shebangs for (gem irb erb ri rdoc testrb rake).
6:03:33 AM: Install of ruby-3.3.6 - #complete
6:03:33 AM: Ruby was built without documentation, to build it run: rvm docs generate-ri
6:03:33 AM: Using /opt/buildhome/.rvm/gems/ruby-3.3.6
6:03:34 AM: Using Ruby version 3.3.6

The pattern seems pretty consistent, with every other build taking at least twice as long as the previous one:

Any ideas of why this is happening?

hey @gesteves thanks for getting in touch and apologies for the delay on this one! I took a quick peek at each deploy on the main branch over the past few days, and each looks to have successfully restored the cached Ruby gems, and was built and deployed in < 1 minute (it also looks like the current Ruby version in use is 3.4.1), so it seems you may have since resolved this issue? let me know!

Hi, I am also facing this - 3.3.6 as well - caching seems to intermittently not work

trying with ruby 3.4.1 and it’s still inconsistent for me

would you mind sharing the site info, or a link to the build logs?

I’m also seeing this.

I have tried 3.4.1 and 3.3.6 and both are compiling from source.

My question is: are there ever any “binary rubies available”?

Or are things always compiled from source and then cached with every ruby/gem change? Seems wasteful to compile from source when it could be a shared cache. Edit: this appears to be the case but I’d like confirmation.

Netlify (3.4.1 cache miss)

Netlify (3.3.6 cache hit)

Thanks for following up and providing this info! I did a bit more digging, and I’m wondering whether this is a Netlify-specific issue, or rather a result of the binaries just not yet being available for these versions of Ruby.

This build log:

No binary rubies available for: ubuntu/20.04/x86_64/ruby-3.4.1.

Led me to this Stack Overflow post:

When installing new Rubies, RVM first tries to use a pre-compiled version it downloads from https://rvm_io.global.ssl.fastly.net/binaries/. This significantly speeds up the installation of Rubies.

Clicking through to Ubuntu version displayed in the above build log - https://rvm_io.global.ssl.fastly.net/binaries/ubuntu/20.04/x86_64/ - it looks like the last Ruby version for which these binaries are available is 3.2.1.

Hi Marcus, but shouldn’t netlify try to find the binaries in the cache first and, failing that, try to get them from rvm? The problem we’re facing is the inconsistent cache hit.

I do understand that what you’re suggesting, i.e. downgrading to 3.2.1 until 3.3.6 or 3.4.1 is available at https://rvm_io.global.ssl.fastly.net/binaries/ubuntu/20.04/x86_64/, might speed things up, but wouldn’t that be just a mitigation for the inconsistent caching netlify is doing?

Indeed, and the reason I upgraded my ruby is because some dependencies require it. I’m using 3.3.6 which isn’t even the latest (it’s from Nov 2024, whereas the current latest is 3.4.1 from Dec 2024).

My site keen-bhaskara-f5872f takes a random variable amount of time to deploy. Sometimes as quick as 40 seconds, other times 240 seconds (4 minutes). I would expect a deploy following a slow one to be quicker, but that’s not always the case. I did two deploys just now and the first was quick and the second, only six minutes later, was slow.

  • For the quick ones, ruby is restored from cache.
  • For the slow ones, it is indeed compiling ruby from scratch.

Can I control this or improve the situation in any way? I’ve tried clearing the cache but to no avail. I have downgraded to 3.2.1 (from Feb 2023 !?!) but it’s really not something I want to do as it can surely only be a temporary fix and strikes me as not being a great idea in general.