Install Ruby with rbenv

[mattt]

Related to #5031 (comment)

Currently, we use the Brightbox PPA to install Ruby with apt. However, this limits our ability to update to a more recent patch release of Ruby 2.7 (or later, Ruby 3).

This PR updates this step in Dockerfile to instead use rbenv and ruby-install to install and manage ruby versions. I used Ruby 2.7.5 to match the version installed now. As a follow-up, we should upgrade to 2.7.6.

[Nishnha]

LGTM

[Nishnha]

I noticed we used to install ruby-dev which is a package with "header files for compiling extension modules for Ruby".

AFAIK RVM rbenv + ruby-build installs ruby as source for the machine so this might not be a concern?

We might also want to check if this change makes the Docker build take significantly longer in case we are actually building from source instead of pulling a binary

[mattt]

I noticed we used to install ruby-dev which is a package with "header files for compiling extension modules for Ruby".

AFAIK RVM installs ruby as source for the machine so this might not be a concern?

The first commit (bcf435f), I messed up the PATH and ended up running whatever system Ruby was available. And CI failed when attempting to install native extensions because of those missing headers.

The next commit (b591c76) fixed the PATH and everything worked as expected. So I think we should be arlight.

We might also want to check if this change makes the Docker build take significantly longer in case we are actually building from source instead of pulling a binary

That shouldn't be as much of a concern on subsequent builds if the layer is cached. But yeah, it'll be interesting to see what difference that makes.

[deivid-rodriguez]

I'm totally in favor of going this route instead of keep using Ruby packaged by the OS 👍.

Also, just to make sure, there's another popular software called ruby-install, but this PR intends to use ruby-build, correct?

Finally, do we need rbenv at all? Rbenv is normally used when you need to frequently switch between Ruby versions, but in this case, there's a single Ruby version. It could be fine, only gotcha I see is that boot time of ruby scripts is slower, since every Ruby executable has to go through a shim to "redirect" to the one from the right version. But it's probably not a big deal for us? Anyways, if wanted I think we may be able to get rid of rbenv by directly configuring PATH?

[jeffwidman]

Thanks for handling this!

[DavidTurner-N]

Is there a plan for when this PR is going to be merged in please? And will it unblock #5030 ?

Thanks!

[Nishnha]

I did some more reading on this topic and it seems like what this PR proposes, using rbenv + ruby-build, covers all the bases for installing Ruby from source and changing the necessary paths for our Docker shell. So this approach seems fine to deploy and unblock #5030

There are a couple of alternatives to rbenv and ruby-build though:

• We could use chruby, an alternative to rbenv that doesn't use shims. This might be be worth looking into since shimming can be expensive. @deivid-rodriguez what do you think? Bundler jobs already have a longer average runtime than other ecosystem, could this make a difference? As far as I can tell, Dependabot doesn't actually change its Ruby version after the Docker image is built.

• We could also use ruby-install instead of ruby-build, which means running ruby-install ruby 2.7 in our Dockerfile would pull the latest patch version (instead of manually having to set the exact version with ruby-build). We already have to manually increment the supported Ruby versions in

  dependabot-core/bundler/lib/dependabot/bundler/file_updater/ruby_requirement_setter.rb

  Lines 13 to 15 in e102933

  	RUBY_VERSIONS = %w(
  	1.8.7 1.9.3 2.0.0 2.1.10 2.2.10 2.3.8 2.4.10 2.5.9 2.6.7 2.7.3 3.0.1 3.1.1
  	).freeze

  anyway though, so it's not a big deal.

One potential side effect we should check before deploying is that rbenv won't try to change the local ruby version if it detects a .ruby-version file in a project, which might happen when we use SharedHelpers to execute commands in a temporary project directory.
Since we already set the BUNDLER_VERSION environment variable in our Helpers when calling bundler, we could likewise set the RBENV_VERSION?

dependabot-core/bundler/helpers/v1/build

Lines 23 to 27 in e102933

	# NOTE: Sets `BUNDLED WITH` to match the installed v1 version in Gemfile.lock
	# forcing native helpers to run with the same version
	BUNDLER_VERSION=1.17.3 bundle config --local path ".bundle"
	BUNDLER_VERSION=1.17.3 bundle config --local without "test"
	BUNDLER_VERSION=1.17.3 bundle install

---

A couple notes:

• Using rbenv is in-line with our recommended setup instructions in the Dependabot contributing doc

• Seems like we have the required build dependencies 👍🏾

• The instructions for using rbenv with ruby-build is to install ruby-build as a plugin, but the Dockerfile changes in this PR just installs Ruby to a common path. I'm not sure if one is preferable to the other here though.

[deivid-rodriguez]

@Nishnha Yes, it's true that chruby could be better since it doesn't use shims, but my idea was to avoid installing and using any ruby switcher at all since we don't really need to switch rubies. I'm happy to further investigate this idea.

[mattt]

Thanks for sharing your thoughts, @Nishnha @deivid-rodriguez! I agree that the additional switching behavior of rbenv could be problematic for our particular use case, so I opened #5356 as an alternative.