ruby / setup-ruby

An action to download a prebuilt Ruby and add it to the PATH in 5 seconds

setup-ruby

This action downloads a prebuilt ruby and adds it to the PATH.

It is very efficient and takes about 5 seconds to download, extract and add the given Ruby to the PATH. No extra packages need to be installed.

Important: Prefer ruby/setup-ruby@v1. If you pin to a commit or release, only the Ruby versions available at the time of the commit will be available, and you will need to update it to use newer Ruby versions, see Versioning.

Supported Versions

This action currently supports these versions of MRI, JRuby and TruffleRuby:

Interpreter	Versions
ruby	1.9.3, 2.0.0, 2.1.9, 2.2, all versions from 2.3.0 until 3.4.0-preview1, head, debug, mingw, mswin, ucrt
jruby	9.1.17.0 - 9.4.8.0, head
truffleruby	19.3.0 - 24.0.1, head
truffleruby+graalvm	21.2.0 - 24.0.1, head

ruby-debug is the same as ruby-head but with assertions enabled (-DRUBY_DEBUG=1).

Regarding Windows ruby master builds, mingw is a MSYS2/MinGW build, head & ucrt are MSYS2/UCRT64 builds, and mswin is a MSVC/VS 2022 build.

Preview and RC versions of Ruby might be available too on Ubuntu and macOS (not on Windows). However, it is recommended to test against ruby-head rather than previews, as it provides more useful feedback for the Ruby core team and for upcoming changes.

Only release versions published by RubyInstaller are available on Windows. Due to that, Ruby 2.2 resolves to 2.2.6 on Windows and 2.2.10 on other platforms. Ruby 2.3 on Windows only has builds for 2.3.0, 2.3.1 and 2.3.3.

Note that Ruby ≤ 2.4 and the OpenSSL version it needs (1.0.2) are both end-of-life, which means Ruby ≤ 2.4 is unmaintained and considered insecure.

Supported Platforms

The action works on these GitHub-hosted runners images. Runner images not listed below are not supported yet. $OS-latest just alias to one of these images.

Operating System	Supported
Ubuntu	ubuntu-20.04, ubuntu-22.04, ubuntu-24.04
macOS	macos-12, macos-13, macos-14
Windows	windows-2019, windows-2022

The prebuilt releases are generated by ruby-builder and on Windows by RubyInstaller2. The mingw, ucrt and mswin builds are generated by ruby-loco. ruby-head is generated by ruby-dev-builder, jruby-head is generated by jruby-dev-builder, truffleruby-head is generated by truffleruby-dev-builder and truffleruby+graalvm is generated by graalvm-ce-dev-builds. The full list of available Ruby versions can be seen in ruby-builder-versions.json for Ubuntu and macOS and in windows-versions.json for Windows.

Usage

Single Job

name: My workflow
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4
    - uses: ruby/setup-ruby@v1
      with:
        ruby-version: '3.3' # Not needed with a .ruby-version file
        bundler-cache: true # runs 'bundle install' and caches installed gems automatically
    - run: bundle exec rake

Matrix of Ruby Versions

This matrix tests all stable releases and head versions of MRI, JRuby and TruffleRuby on Ubuntu and macOS.

name: My workflow
on: [push, pull_request]
jobs:
  test:
    strategy:
      fail-fast: false
      matrix:
        os: [ubuntu-latest, macos-latest]
        # Due to https://github.com/actions/runner/issues/849, we have to use quotes for '3.0'
        ruby: ['2.7', '3.0', '3.1', '3.2', '3.3', head, jruby, jruby-head, truffleruby, truffleruby-head]
    runs-on: ${{ matrix.os }}
    steps:
    - uses: actions/checkout@v4
    - uses: ruby/setup-ruby@v1
      with:
        ruby-version: ${{ matrix.ruby }}
        bundler-cache: true # runs 'bundle install' and caches installed gems automatically
    - run: bundle exec rake

Matrix of Gemfiles

name: My workflow
on: [push, pull_request]
jobs:
  test:
    strategy:
      fail-fast: false
      matrix:
        gemfile: [ rails5, rails6 ]
    runs-on: ubuntu-latest
    env: # $BUNDLE_GEMFILE must be set at the job level, so it is set for all steps
      BUNDLE_GEMFILE: ${{ github.workspace }}/gemfiles/${{ matrix.gemfile }}.gemfile
    steps:
      - uses: actions/checkout@v4
      - uses: ruby/setup-ruby@v1
        with:
          ruby-version: '3.3'
          bundler-cache: true # runs 'bundle install' and caches installed gems automatically
      - run: bundle exec rake

See the GitHub Actions documentation for more details about the workflow syntax and the condition and expression syntax.

Supported Version Syntax

• engine-version like ruby-2.6.5 and truffleruby-19.3.0
• short version like '2.6', automatically using the latest release matching that version (2.6.10)
• version only like '2.6.5', assumes MRI for the engine
• engine only like ruby and truffleruby, uses the latest stable release of that implementation
• .ruby-version reads from the project's .ruby-version file
• .tool-versions reads from the project's .tool-versions file
• If the ruby-version input is not specified, .ruby-version is tried first, followed by .tool-versions

Working Directory

The working-directory input can be set to resolve .ruby-version, .tool-versions and Gemfile.lock if they are not at the root of the repository, see action.yml for details.

RubyGems

By default, the default RubyGems version that comes with each Ruby is used. However, users can optionally customize the RubyGems version that they want by setting the rubygems input.

See action.yml for more details about the rubygems input.

If you're running into ArgumentError: wrong number of arguments (given 4, expected 1) errors with a stacktrace including Psych and RubyGems entries, you should be able to fix them by setting rubygems: 3.0.0 or higher.

Bundler

By default, Bundler is installed as follows:

• If there is a Gemfile.lock file (or $BUNDLE_GEMFILE.lock or gems.locked) with a BUNDLED WITH section, that version of Bundler will be installed and used.
• If the Ruby ships with Bundler 2.2+ (as a default gem), that version is used.
• Otherwise, the latest compatible Bundler version is installed (Bundler 2 on Ruby >= 2.3, Bundler 1 on Ruby < 2.3).

This behavior can be customized, see action.yml for more details about the bundler input.

Caching bundle install automatically

This action provides a way to automatically run bundle install and cache the result:

    - uses: ruby/setup-ruby@v1
      with:
        bundler-cache: true

Note that any step doing bundle install (for the root Gemfile) or gem install bundler can be removed with bundler-cache: true.

This caching speeds up installing gems significantly and avoids too many requests to RubyGems.org.
It needs a Gemfile (or $BUNDLE_GEMFILE or gems.rb) under the working-directory.
If there is a Gemfile.lock (or $BUNDLE_GEMFILE.lock or gems.locked), bundle config --local deployment true is used.

To use a Gemfile which is not at the root or has a different name, set BUNDLE_GEMFILE in the env at the job level as shown in the example.

bundle config

When using bundler-cache: true you might notice there is no good place to run bundle config ... commands. These can be replaced by BUNDLE_* environment variables, which are also faster. They should be set in the env at the job level as shown in the example. To find the correct the environment variable name, see the Bundler docs or look at .bundle/config after running bundle config --local KEY VALUE locally. You might need to "-quote the environment variable name in YAML if it has unusual characters like /.

To perform caching, this action will use bundle config --local path $PWD/vendor/bundle.
Therefore, the Bundler path should not be changed in your workflow for the cache to work (no bundle config path).

How it Works

When there is no lockfile, one is generated with bundle lock, which is the same as bundle install would do first before actually fetching any gem. In other words, it works exactly like bundle install. The hash of the generated lockfile is then used for caching, which is the only correct approach.

Dealing with a corrupted cache

In some rare scenarios (like using gems with C extensions whose functionality depends on libraries found on the system at the time of the gem's build) it may be necessary to ignore contents of the cache and get and build all the gems anew. In order to achieve this, set the cache-version option to any value other than 0 (or change it to a new unique value if you have already used it before.)

    - uses: ruby/setup-ruby@v1
      with:
        bundler-cache: true
        cache-version: 1

Caching bundle install manually

It is also possible to cache gems manually, but this is not recommended because it is verbose and very difficult to do correctly. There are many concerns which means using actions/cache is never enough for caching gems (e.g., incomplete cache key, cleaning old gems when restoring from another key, correctly hashing the lockfile if not checked in, OS versions, ABI compatibility for ruby-head, etc). So, please use bundler-cache: true instead and report any issue.

Windows

Note that running CI on Windows can be quite challenging if you are not very familiar with Windows. It is recommended to first get your build working on Ubuntu and macOS before trying Windows.

• Use Bundler 2.2.18+ on Windows (older versions have bugs) by not setting the bundler: input and ensuring there is no BUNDLED WITH 1.x.y in a checked-in Gemfile.lock.
• The default shell on Windows is not Bash but PowerShell. This can lead issues such as multi-line scripts not working as expected.
• The PATH contains multiple compiler toolchains. Use where.exe to debug which tool is used.
• For Ruby ≥ 2.4, MSYS2 is prepended to the Path, similar to what RubyInstaller2 does.
• For Ruby < 2.4, the DevKit MSYS tools are installed and prepended to the Path.
• Use JRuby 9.2.20+ on Windows (older versions have bugs).
• JRuby on Windows has multiple issues (jruby/jruby#7106, jruby/jruby#7182).

Versioning

It is highly recommended to use ruby/setup-ruby@v1 for the version of this action. This will provide the best experience by automatically getting bug fixes, new Ruby versions and new features.

If you instead choose a specific version (v1.2.3) or a commit sha, there will be no automatic bug fixes and it will be your responsibility to update every time the action no longer works. Make sure to always use the latest release before reporting an issue on GitHub.

This action follows semantic versioning with a moving v1 branch. This follows the recommendations of GitHub Actions.

Using self-hosted runners

This action might work with self-hosted runners if the Runner Image is very similar to the ones used by GitHub runners. Notably:

• Make sure to use the same operating system and version.
• Make sure to use the same version of libssl.
• Make sure that the operating system has libyaml-0 and libgmp installed
• The default tool cache directory (/opt/hostedtoolcache on Linux, /Users/runner/hostedtoolcache on macOS, C:/hostedtoolcache/windows on Windows) must be writable by the runner user. This is necessary since the Ruby builds embed the install path when built and cannot be moved around.
• /home/runner must be writable by the runner user.

In other cases, you will need to install Ruby in the runner tool cache as shown by the action when it detects that case (run it so it will show you where to install Ruby). You could of course also not use this action and e.g. use Ruby from a system package or use a Docker image instead.

See also the self-hosted: input. You can set it to true if you want to use custom-built Rubies in your self-hosted toolcache instead of prebuild Rubies.

History

This action used to be at eregon/use-ruby-action and was moved to the ruby organization. Please update if you are using eregon/use-ruby-action.

Credits

The current maintainer of this action is @eregon. Most of the Windows logic is based on work by MSP-Greg. Many thanks to MSP-Greg and Lars Kanis for the help with Ruby Installer.

setup-ruby's Issues

macOS Ruby 2.7 - built with OpenSSL 1.0.2t 10 Sep 2019

Long story how I noticed it. As you may recall, macOS Ruby 2.4, 2.5 & 2.6 are built with 1.1.1.

Bundler / RubyGems - upgrade just Bundler or both?

There was just an odd CI failure in a Puma PR, with only 2.5.& 2.6 failing on Windows. Ubuntu & macOS passed.

I tried to repo locally, using 2.6.5 as setup by Actions (with Bundler < 2), I had some odd issues. I grabbed the Puma PR in my fork, and re-ran the CI, both with the --seed value that failed in Puma and without, and both passed.

While working with various repo's CI and Ruby < 2.6.0 (no included Bundler), I think people have had more 'success' by running gem update --system (Ruby >= 2.3), rather than gem install bundler.

IOW, this is about the distinction of whether available CI builds (Ruby >= 2.3) should have only Bundler installed, or whether they should have gem update --system done.

Wanted to have an open issue in case others have similar problems...

Please consider BUNDLE_GEMFILE env variable

The current version (5a76bd6) of the readme says

By default, if there is a Gemfile.lock file with a BUNDLED WITH section,
the latest version of Bundler with the same major version will be installed.
Otherwise, the latest Bundler version is installed (except for Ruby 2.2 and 2.3 where only Bundler 1 is supported).

This behavior can be customized, see action.yml for details about the bundler input.

When doing gem development it’s not uncommon to have CI testing various combinations of gem dependencies, for example
testing a Rails-specific library against e.g. Rails v4.2, v5.2 and v6.0.

To accomplish this, I usually have a gemfiles folder containing a number of gemfiles, and I would configure GitHub Actions like this:

strategy:
  matrix:
    gemfile:
      - gemfiles/rails4.2.gemfile
      - gemfiles/rails5.2.gemfile
      - gemfiles/rails6.0.gemfile
steps:
  - uses: actions/checkout@v2
  - uses: ruby/setup-ruby@v1
  - run: echo "::set-env name=BUNDLE_GEMFILE::$GITHUB_WORKSPACE/${{ matrix.gemfile }}"
  …

Since I wouldn’t add Gemfile.lock to the repository, ruby/setup-ruby will automatically install Bundler v2 for all three gemfiles. And since Rails 4.2 is restricted to versions >= 1.3.0, < 2.0 of Bundler, my tests cannot run.

Would it be possible to change ruby/setup-ruby to consider the contents of $BUNDLE_GEMFILE + ".lock" before Gemfile.lock (when $BUNDLE_GEMFILE exists)?

Notes:

• BUNDLE_GEMFILE is mentioned in https://bundler.io/v2.1/man/bundle-config.1.html
• There is a tool for testing with multiple gemfiles, called “Appraisal”. It seems to work by setting BUNDLE_GEMFILE before each run.

Windows - ruby-head, ruby-mswin

@eregon

I got the mingw work done in a branch, it was nice to run yarn, yarn run lint, & yarn run package and see only one line changed in dist/index.js. I did update yarn.lock, if that's ok.

Question - should the mswin ruby-version string be 'ruby-mswin'? Obviously, if one is using a single workflow/job layout in Actions, one would need to exclude all OS's except Windows.

It's easy to add, as it's a hard URI, but I'd like to think about whether MSYS2 should be activated or not. I'm thinking not. I'm also wondering whether the 'package action' should be available with it's addition/release. Remember, the main reason I created the build was for stdlib extension gems that are in the Ruby account/organization.

Off topic Windows stuff:

Please see:
https://github.com/MSP-Greg/ruby-setup-ruby/runs/449427016?check_suite_focus=true#step:5:8

I added that line, it shows the gcc version that the Ruby build was compiled with. Note:

(Rev2, Built by MSYS2 project) 9.2.0

Now, in the same step, note line 19:

(Rev2, Built by MSYS2 project) 8.3.0

If you check the most recent action at MSP-Greg/ruby-setup-ruby-info, you'll see that all the recent Ruby binaries were compiled with gcc 9.2.0 Rev 2 (see Ruby info step, ~ line 10 gcc info:). But, the DevKit version, which is shown by 'ridk version' is 8.2.0 Rev 2.

That is the reason I've always had code to update the gcc tools in my Windows actions. But, importantly, updating gcc tools can cause issues with older Ruby binaries, like 2.5.0 or 2.6.0. Long story, it's due adding libssp (Smashing Stack Protector) to gcc in one of the 9.2.0 releases.

Finally, note line 15:

package_version: ruby-loco RI2 2.7.0-1

I modified a file to add the 'ruby-loco', and that is the easiest way to determine where the build came from.

Off topic Actions:

In ruby-loco I have an embedded action that handles the release asset uploading. I prefer to have hard URI, so I set it up as follows:

1. Upload replacement build asset with filename 'new_ruby_mingw.7z'
2. Delete current asset
3. Rename 'new_ruby_mingw.7z' to 'ruby_mingw.7z'

Steps 2 & 3 take around 400 mS. I haven't tried to see what happens during that time period, nor does the GiHub API allow any sort of 'transaction' block...

[misc] ubuntu-latest will be 20.04, macOS-11.0 Big Sur

You've probably seen them, but just in case:

actions/runner-images#1816 - Ubuntu-latest workflows will use Ubuntu-20.04

Other than the changed OpenSSL 'security_level', not much of a change between 19.04 and 20.04. I have suggested that workflows use the numeric style rather than 'latest'...

actions/runner-images#1814 - macOS 11.0 (Big Sur) is available as a preview

Not knowledgeable re macOS. I have used a 10.15 Ruby build with 11.0. They don't mention whether they will be removing 10.15 or not. Then again, they mentioned that windows-2016 would be removed a long time ago...

Add Ruby versions fixing heap exposure vulnerabililty

https://www.ruby-lang.org/en/news/2020/03/31/heap-exposure-in-socket-cve-2020-10933/

Versions released to fix this:

• 2.7.1
• 2.6.6
• 2.5.8
• 2.4.10

JRuby on Windows doesn't seem to work

I tried using JRuby on Windows through use-ruby-action, but looks like it hangs. I'm not sure what exactly is going on there because bundle install step has finished, but next step that is supposed to run RSpec, doesn't contain any output at all.

Minify dist, bring back eslint?

Before updating to the new @actions/cache code (v1.0.2), the dist/index.js file was ~ 600K. After the update it's about ~ 2M. Using ncc build index.js -o dist -m drops it to about 935K. Might be something to consider.

Also, since minifying can make debugging more difficult, maybe return to using eslint?

setup-ruby interferes with Windows runner's own MSYS2 install

setup-ruby/windows.js

Lines 121 to 124 in 002b15e

	// Remove when Actions Windows image contains MSYS2 install
	if (!fs.existsSync(msys2)) {
	await symLinkToEmbeddedMSYS2()
	}

actions/runner-images#905 (comment)

I believe it is time to remove this bit of setup. If it is not, how can I opt out of setup-ruby including a bundled MSYS2?

Honor default.run.working-directory?

I'm currently working on a mono repo project where there's a Rails application in one subdirectory and a React application in another. We have workflow files for each project and change the default working directory so all commands run in the correct path:

defaults:
  run:
    working-directory: rails_app

It would be nice if this action could read in that value rather than having me duplicate it in the action's with clause, in order for the .ruby-version file to be found. I've never looked at the GitHub Actions API, so apologies if I'm asking for something that isn't doable.

Integrate system operations into setup-ruby

Thinking about what 's needed for some of the repos I've worked in, I'm wondering if integrating some of the MSYS2 related things I've done in msys2-action and actions-ruby could be integrated here.

For instance, inputs could be added like:

with:

  pkg: ragel
  macOS:
  mingw:
  ubuntu:

EDIT: for instance, all the code needed for ragel

      - name: ubuntu & macos - install ragel
        if:   startsWith(matrix.os, 'ubuntu') || startsWith(matrix.os, 'macos')
        run:  |
          if [ "${{ matrix.os }}" == "macos" ]; then
            brew install ragel
          else
            sudo apt-get -qy install ragel
          fi

'ragel' is a package with a cross platform name, so code could install it based on the platform used. For packages without common names, the OS specific names could be used in the respective inputs.

I recall somewhere seeing something like 'brew update all' or a similar command, which for Windows/MSYS2 might be the equivalent of updating the gcc tools. Just some general thoughts...

Branches and Tagging Don't Match Github Recommendations

Right now, v1 is a branch, which works, but there really should be a v1 tag pointing to the latest v1 release:

Move the major version tag (v1, v2, etc.) to point to the Git ref of the current release. For more information, see "Git basics - tagging."
https://help.github.com/en/actions/building-actions/about-actions#versioning-your-action

Windows - switch to MSYS2 bash shell ?

I've got the MSYS2 bash shell running as the default in my fork.

Using Reline, I set up a workflow where all jobs ran tests both using pwsl (PowerShell Core) and MSYS2 bash. All jobs (Ubuntu, macOS, Win) passed .

Bundler's tests will only run using bash, and they also pass, see https://github.com/MSP-Greg/rubygems/actions/runs/131762536

The one issue is we need to re-arrange things so there is some code that runs for all Rubies on Windows, as it needs to run for Windows JRuby jobs.

The code is in the commit MSP-Greg@b2da215d2df

Thoughts?

EDIT:

Haven't implemented it yet, but this issue is about ENV['Path'] handling. I think the best way to handle it is below:

1. Remove system Ruby from Path
2. Add msys2PathEntries to Path
3. Install Ruby
4. Add build specific entries (MSYS for Ruby 2.3 and earlier, MSVC for mswin)
5. Add Ruby bin folder

HTTP 404 when attempting to install Ruby on windows-latest

Excellent work on use-ruby-action! 🙏

When using the action on Windows, it looks like it may not be correctly performing Windows-specific actions to download Ruby from RubyInstaller. Instead, it 404s, attempting to download the binary from ruby-install-builder.

Here is an example run where the failure is encountered:
https://github.com/starship/starship/runs/395744542

ruby/setup-ruby@v1 does not run in a self-hosted runner

I can't run ruby/setup-ruby@v1 in a self-hosted runner. My action works fine in GitHub-hosted runner ubuntu-latest but I tried with my own docker image, the myoung34/github-runner:ubuntu-focal image and tcardonne/github-runner:ubuntu-20.04 and VM with Ubuntu 20.04. I always get the same error:

I tried ruby 2.6 and 2.7, looks like node can't spawn the process. Maybe a missing dependency in the runner?

##[error]There was an error when attempting to execute the process '/root/.rubies/ruby-2.7.1/bin/gem'. This may indicate the process failed to start. Error: spawn /root/.rubies/ruby-2.7.1/bin/gem ENOENT

My simple repo to test this: https://github.com/navarroaxel/ruby-runner/runs/1133643210

My workflow:

name: Ruby
on: push
jobs:
  publish:
    runs-on: self-hosted
    steps:
    - uses: actions/checkout@v2
    - uses: ruby/[email protected]
      with:
        ruby-version: 2.7

output:

 Run ruby/setup-ruby@v1
  Took   0.00 seconds
Run ruby/setup-ruby@v1
  with:
    ruby-version: 2.7
    bundler: default
    bundler-cache: false
    working-directory: .
Downloading Ruby
  https://github.com/ruby/ruby-builder/releases/download/enable-shared/ruby-2.7.1-ubuntu-20.04.tar.gz
  Took  23.29 seconds
Extracting Ruby
  /usr/bin/tar -xz -C /root/.rubies -f /tmp/work/_temp/acd71600-4e4d-4beb-bca0-db920cc72d0c
  Took   0.34 seconds
Installing Bundler
  /root/.rubies/ruby-2.7.1/bin/gem install bundler -v ~> 2 --no-document
  Took   0.00 seconds
##[error]There was an error when attempting to execute the process '/root/.rubies/ruby-2.7.1/bin/gem'. This may indicate the process failed to start. Error: spawn /root/.rubies/ruby-2.7.1/bin/gem ENOENT

If I run the downloaded binaries in the VM I get this error:

$ ./.rubies/ruby-2.7.1/bin/gem 
-bash: ./../.rubies/ruby-2.7.1/bin/gem: /home/runner/.rubies/ruby-2.7.1/bin/ruby: bad interpreter: No such file or directory
$ ./.rubies/ruby-2.7.1/bin/ruby 
./.rubies/ruby-2.7.1/bin/ruby: error while loading shared libraries: libruby.so.2.7: cannot open shared object file: No such file or directory

Windows Rubies - proper download URI

@eregon

The following line adds a suffix:

https://github.com/eregon/use-ruby-action/blob/7978ff15791e44ccfeaedff4a522ad0be7b68079/windows.js#L16

Below is a truncated GraphQL grab of the releases, you'll notice a few have a suffix of -2. I believe this was done when build issues, RIDK/devkit issues, etc were noticed after the original -1 release.

I was waiting on this pending how things went with GitHub. I also have the flu, so I'm not big on writing code right now. I just thought I'd make you aware of it.

I don't know whether adding a json/yaml file for Windows URI mapping is a good idea, but checking for releases in the action itself seems a bit much. All my GraphQL code is Ruby; I could have it generate a json/yaml file...

{"name"=>"RubyInstaller-2.5.1-2 - 2018-06-24"},
{"name"=>"RubyInstaller-2.4.4-2 - 2018-06-24"},
{"name"=>"RubyInstaller-2.5.1-1 - 2018-03-29"},
{"name"=>"RubyInstaller-2.4.4-1 - 2018-03-29"},
{"name"=>"RubyInstaller-2.5.0-2 - 2018-02-27"},
{"name"=>"RubyInstaller-2.4.3-2 - 2018-02-27"},
{"name"=>"RubyInstaller-2.5.0-1 - 2017-12-25"},
{"name"=>"rubyinstaller-head"},
{"name"=>"RubyInstaller-2.4.3-1 - 2017-12-20"},
{"name"=>"RubyInstaller-2.4.2-2 - 2017-09-15"},
{"name"=>"RubyInstaller-2.4.2-1 - 2017-09-15"},
{"name"=>"RubyInstaller-2.4.1-2 - 2017-07-04"},
{"name"=>"RubyInstaller-2.4.1-1 - 2017-05-25"},

Version 2.5.7 not found

My actions are suddenly unable to setup ruby v2.5.7

 Setup Ruby
##[debug]Finishing: Setup Ruby
##[debug]Evaluating condition for step: 'Setup Ruby'
##[debug]Evaluating: success()
##[debug]Evaluating success:
##[debug]=> true
##[debug]Result: true
##[debug]Starting: Setup Ruby
##[debug]Loading inputs
##[debug]Loading env
Run actions/setup-ruby@v1
  with:
    ruby-version: 2.5.7
##[debug]isExplicit: 2.5.7
##[debug]explicit? true
##[debug]checking cache: /opt/hostedtoolcache/Ruby/2.5.7/x64
##[debug]not found
##[error]Version 2.5.7 not found
##[debug]Node Action run completed with exit code 1
##[debug]Finishing: Setup Ruby

sassc-ruby fails to install on Windows + JRuby

See test project and build log.

I've also reported this bug as sass/sassc-ruby#214 because I'm not sure what party is to blame here.

Fix "Insecure world writable dir ... in PATH" warnings

Reported by @benoittgt

This is the same as actions/runner-images#267 but meant to track how to solve it for this action.

To fix it (at least for now), I'll rebuild all MRI releases with CPPFLAGS="-DENABLE_PATH_CHECK=0" ./configure ... as mentioned in actions/runner-images#267 (comment)

Enable use from other Actions

Sometimes, we do not care about installing Ruby per se: we want some tool that happens to use Ruby. One example is building a static website with Hugo and Asciidoc -- which happens to depend on asciidoctor as an external dependency, despite neither Hugo devs nor page creators seeing a single line of Ruby.

So, we want to install asciidoctor and not care about how it's done, e.g. through this action I just wrote. Unfortunately, since actions can't call each other, every user has to repeat the call of ruby/setup-ruby.

A recommended workaround seems to be for actions to factor out their core functionality into functions that can be imported and called from other actions.

Fails to install ruby 2.3

I'm getting the following error:

Run actions/setup-ruby@v1
2  with:
3   ruby-version: 2.3
4 ##[error]Version 2.3 not found
5 ##[error]Node run failed with exit code 1

Automated Bundler caching

I'd like to add automated Bundler caching in this action, since caching manually like https://github.com/ruby/setup-ruby/blob/master/README.md#caching-bundle-install is quite verbose and hard to get right (e.g., sass/sassc-ruby#183 (comment)).

It would be optional, not sure about the default yet.

For that to work, we need actions/cache to be a package, so this needs actions/cache#55 first.

bundle install fails on windows-latest after using bundle config

If I use bundle config to set bundler options (e.g., bundle config --local without docs), the subsequent call to bundle install fails. The action gives no reason why it failed.

##[error]Process completed with exit code 1.

This does not happen on ubuntu-latest.

JRuby Windows, compiling & Actions

@headius @eregon

I saw PR #35, was led to jruby/jruby-launcher, and saw mention of MinGW.

Not being very familiar with JRuby, is there a need for compile tools on Windows? Also, I believe Java itself is compiled with MSVC/mswin tools, not MinGW tools.

With the current code here, there is no way to enable compile tools on Windows unless the Ruby platform is MRI mswin or mingw. Enabling mswin is simple and fast, but (long story) enabling mingw takes a minute or two.

ruby 2.7.2

Ruby 2.7.2 was released:
https://www.ruby-lang.org/en/news/2020/10/02/ruby-2-7-2-released/

JRuby on Windows: "bundler: command not found: rake"

Actions config used:

jobs:
  build:
    name: '${{ matrix.os }}: ${{ matrix.ruby }}'
    strategy:
      fail-fast: false
      matrix:
        os: [ ubuntu-latest, windows-latest ]
        ruby: [ 2.4, 2.5, 2.6, 2.7, jruby, truffleruby ]
    runs-on: ${{ matrix.os }}
    steps:
    - uses: actions/checkout@v2
    - name: Set up Ruby ${{ matrix.ruby }}
      uses: ruby/setup-ruby@v1
      with:
        ruby-version: ${{ matrix.ruby }}
    - run: ruby -v
    - run: bundle install --jobs 4 --retry 3
    - run: bundle exec rake

Output from the bundle exec rake step

Run bundle exec rake
  bundle exec rake
  shell: C:\Program Files\PowerShell\6\pwsh.EXE -command ". '{0}'"
bundler: command not found: rake
Install missing gem executables with `bundle install`
##[error]Process completed with exit code 1.

The bundle install step before do install rake

I assume JRuby on Windows should work out-of-the-box, right? Am I doing something wrong?

I saw #12, so I checked the asciidoctor-epub3 repo, they are installing bundler themselves, maybe that makes a difference somewhere

---

Status: see #18 (comment) and below

Support for shared built Rubies

In order to support embedding Ruby inside other C projects.

Support for `.tool-versions` file

Similar to .ruby-version support, consider supporting .tool-versions: a file used by https://github.com/asdf-vm/asdf to manage multiple language/tool versions in a single place.

Here is a sample of what .tool-versions looks like:

ruby 2.6.5
nodejs 10.13.0

Ideally, if no version is specified for in the workflow step, check for .ruby-version, then .tool-versions as the default.

Permission error when testing a gem with a binary

I am in the process of converting my actions/setup-ruby to ruby/setup-ruby and encountered one difference for the worse in ruby/setup-ruby.

I have an rspec test suite that runs its own binary file, located in the bin folder:

it "errors gracefully" do
  expect(`bin/radio playlist init hello`).to match_approval('bin/premium_error')
end

This causes a permission error when using the Ruby-maintained action (the failing YAML):

  1) bin/radio error handling errors gracefully
     Failure/Error: expect(`bin/radio playlist init hello`).to match_approval('bin/premium_error')

     Errno::EACCES:
       Permission denied - bin/radio
     # ./spec/audio_addict/bin_errors_spec.rb:11:in ``'
     # ./spec/audio_addict/bin_errors_spec.rb:11:in `block (2 levels) in <top (required)>'

And for comparison, it works fine when using the GitHub-developed Ruby action (the passing YAML).

Add support for Amazon Linux 2

Add support for more Linux distributions like Amazon Linux 2. Maybe using the Ruby Version Manager.

ref: #88 (comment)

"tar (child): Cannot connect to d: resolve failed" error when intalling on Windows

Run eregon/use-ruby-action@v1
  with:
    ruby-version: jruby
https://github.com/ruby/ruby-builder/releases/download/builds-no-warn/jruby-9.2.10.0-windows-latest.tar.gz
"C:\Program Files\Git\usr\bin\tar.exe" xz -C C:\Users\runneradmin\.rubies -f d:\a\_temp\faffe4a1-577f-4d8d-912c-b897e86696ba
tar (child): Cannot connect to d: resolve failed

gzip: stdin: unexpected end of file
/usr/bin/tar: Child returned status 128
/usr/bin/tar: Error is not recoverable: exiting now
##[error]The process 'C:\Program Files\Git\usr\bin\tar.exe' failed with exit code 2

Failure log: https://github.com/slonopotamus/asciidoctor-epub3/runs/474587790?check_suite_focus=true#step:3:6

No changes were done in repo since previous run 3 days ago that worked successfully: https://github.com/slonopotamus/asciidoctor-epub3/runs/467944869?check_suite_focus=true#step:3:5

There's also evidence that it worked yesterday: https://github.com/asciidoctor/asciidoctor-pdf/runs/471779090

Same failure in a different project: https://github.com/asciidoctor/asciidoctor-pdf/runs/474207029#step:3:8

Support for short version syntax

It would be very helpful if this action supported short version syntax too, examples:

• ruby-2.6
• jruby-9.2.9
• truffleruby-19.3

cannot load such file -- bundler/gem_tasks with Ruby 2.3 and Bundler 2

I've been using this action for a bit to test a gem for all ruby versions from 2.3 - 2.7. CI hadn't run on it for about a month, and I see now that the behavior of which bundler version is installed by default has changed. I am hitting this error on the ruby 2.3 tests with the latest version of this action which I did not with previous versions:

Run bundle exec rake spec
rake aborted!
LoadError: cannot load such file -- bundler/gem_tasks
/home/runner/work/str_metrics/str_metrics/Rakefile:3:in `require'
/home/runner/work/str_metrics/str_metrics/Rakefile:3:in `<top (required)>'
/home/runner/work/str_metrics/str_metrics/vendor/bundle/ruby/2.3.0/gems/rake-12.3.3/exe/rake:27:in `<top (required)>'
/home/runner/.rubies/ruby-2.3.8/bin/bundle:22:in `load'
/home/runner/.rubies/ruby-2.3.8/bin/bundle:22:in `<main>'
(See full trace by running task with --trace)
##[error]Process completed with exit code 1.

I am guessing it's to do with the action now by default installing bundler 2 where it was installing bundler 1 for older rubies before? Has anyone encountered this? Any pointers/ideas on how to fix would be greatly appreciated! Thank you.

EDIT: I figured out that if I add a gem update --system before my bundle install step, everything seems to run OK. This somehow implies a too old version of rubygems? I saw this after installing ruby2.3 using this action:

gem -v
> 2.5.2.3
gem update --system
gem -v
> 3.1.2

According to https://github.com/rubygems/rubygems#requirements rubygems 3 supports ruby 2.3 and greater. Is there any reason to not use rubygems 3 for my usecase where I'm only supporting rubies greater than 2.3, jruby & truffleruby? I've for now just added a gem update --system to my workflow to workaround this.

Add Rubinius 4

ruby-dev-builder - head builds failing

I noticed that head builds were stuck back 16-June, and had a look at ruby-dev-builder. Issues aren't enabled there, so I posted here.

I made a few changes, and things seem to be passing. See the following, which I ran in my fork:

MSP-Greg/ruby-dev-builder@3fdb427033

The builds are here:
https://github.com/MSP-Greg/ruby-dev-builder/releases/tag/master

I don't know if you can try one locally, not sure if my changes affected the saved builds...

Ruby 2.7 LoadError

Sorry I know this is not the right project to open this issue, sorry in advance.

Wonder if you got any pointers on resolving this LoadError for ruby/www.ruby-lang.org from this PR - The PR itself is irrelevant.

The action workflow file.

Full Error

Checking markdown files... ok
rake aborted!
LoadError: dlopen(/Users/runner/work/www.ruby-lang.org/www.ruby-lang.org/vendor/bundle/ruby/2.7.0/gems/ffi-1.11.1/lib/ffi_c.bundle, 9): Library not loaded: /Users/runner/.rubies/ruby-2.7.1/lib/libruby.2.7.dylib
  Referenced from: /Users/runner/work/www.ruby-lang.org/www.ruby-lang.org/vendor/bundle/ruby/2.7.0/gems/ffi-1.11.1/lib/ffi_c.bundle
  Reason: image not found - /Users/runner/work/www.ruby-lang.org/www.ruby-lang.org/vendor/bundle/ruby/2.7.0/gems/ffi-1.11.1/lib/ffi_c.bundle
/Users/runner/work/www.ruby-lang.org/www.ruby-lang.org/vendor/bundle/ruby/2.7.0/gems/ffi-1.11.1/lib/ffi.rb:6:in `require'
/Users/runner/work/www.ruby-lang.org/www.ruby-lang.org/vendor/bundle/ruby/2.7.0/gems/ffi-1.11.1/lib/ffi.rb:6:in `rescue in <top (required)>'
/Users/runner/work/www.ruby-lang.org/www.ruby-lang.org/vendor/bundle/ruby/2.7.0/gems/ffi-1.11.1/lib/ffi.rb:3:in `<top (required)>'
/Users/runner/work/www.ruby-lang.org/www.ruby-lang.org/vendor/bundle/ruby/2.7.0/gems/sassc-2.2.1/lib/sassc/native.rb:3:in `require'
/Users/runner/work/www.ruby-lang.org/www.ruby-lang.org/vendor/bundle/ruby/2.7.0/gems/sassc-2.2.1/lib/sassc/native.rb:3:in `<top (required)>'
/Users/runner/work/www.ruby-lang.org/www.ruby-lang.org/vendor/bundle/ruby/2.7.0/gems/sassc-2.2.1/lib/sassc.rb:31:in `require_relative'
/Users/runner/work/www.ruby-lang.org/www.ruby-lang.org/vendor/bundle/ruby/2.7.0/gems/sassc-2.2.1/lib/sassc.rb:31:in `<top (required)>'
/Users/runner/work/www.ruby-lang.org/www.ruby-lang.org/vendor/bundle/ruby/2.7.0/gems/jekyll-sass-converter-2.0.1/lib/jekyll/converters/scss.rb:3:in `require'
/Users/runner/work/www.ruby-lang.org/www.ruby-lang.org/vendor/bundle/ruby/2.7.0/gems/jekyll-sass-converter-2.0.1/lib/jekyll/converters/scss.rb:3:in `<top (required)>'
/Users/runner/work/www.ruby-lang.org/www.ruby-lang.org/vendor/bundle/ruby/2.7.0/gems/jekyll-sass-converter-2.0.1/lib/jekyll-sass-converter.rb:4:in `require'
/Users/runner/work/www.ruby-lang.org/www.ruby-lang.org/vendor/bundle/ruby/2.7.0/gems/jekyll-sass-converter-2.0.1/lib/jekyll-sass-converter.rb:4:in `<top (required)>'
/Users/runner/work/www.ruby-lang.org/www.ruby-lang.org/vendor/bundle/ruby/2.7.0/gems/jekyll-4.0.0/lib/jekyll.rb:206:in `require'
/Users/runner/work/www.ruby-lang.org/www.ruby-lang.org/vendor/bundle/ruby/2.7.0/gems/jekyll-4.0.0/lib/jekyll.rb:206:in `<top (required)>'
/Users/runner/work/www.ruby-lang.org/www.ruby-lang.org/vendor/bundle/ruby/2.7.0/gems/lanyon-0.4.1/lib/lanyon.rb:7:in `require'
/Users/runner/work/www.ruby-lang.org/www.ruby-lang.org/vendor/bundle/ruby/2.7.0/gems/lanyon-0.4.1/lib/lanyon.rb:7:in `<top (required)>'
/Users/runner/work/www.ruby-lang.org/www.ruby-lang.org/Rakefile:21:in `require'
/Users/runner/work/www.ruby-lang.org/www.ruby-lang.org/Rakefile:21:in `block in <top (required)>'
/Users/runner/work/www.ruby-lang.org/www.ruby-lang.org/vendor/bundle/ruby/2.7.0/gems/rake-13.0.0/exe/rake:27:in `<top (required)>'
/Users/runner/.rubies/ruby-2.7.2/bin/bundle:23:in `load'
/Users/runner/.rubies/ruby-2.7.2/bin/bundle:23:in `<main>'

Caused by:
LoadError: cannot load such file -- 2.7/ffi_c
/Users/runner/work/www.ruby-lang.org/www.ruby-lang.org/vendor/bundle/ruby/2.7.0/gems/ffi-1.11.1/lib/ffi.rb:4:in `require'
/Users/runner/work/www.ruby-lang.org/www.ruby-lang.org/vendor/bundle/ruby/2.7.0/gems/ffi-1.11.1/lib/ffi.rb:4:in `<top (required)>'
/Users/runner/work/www.ruby-lang.org/www.ruby-lang.org/vendor/bundle/ruby/2.7.0/gems/sassc-2.2.1/lib/sassc/native.rb:3:in `require'
/Users/runner/work/www.ruby-lang.org/www.ruby-lang.org/vendor/bundle/ruby/2.7.0/gems/sassc-2.2.1/lib/sassc/native.rb:3:in `<top (required)>'
/Users/runner/work/www.ruby-lang.org/www.ruby-lang.org/vendor/bundle/ruby/2.7.0/gems/sassc-2.2.1/lib/sassc.rb:31:in `require_relative'
/Users/runner/work/www.ruby-lang.org/www.ruby-lang.org/vendor/bundle/ruby/2.7.0/gems/sassc-2.2.1/lib/sassc.rb:31:in `<top (required)>'
/Users/runner/work/www.ruby-lang.org/www.ruby-lang.org/vendor/bundle/ruby/2.7.0/gems/jekyll-sass-converter-2.0.1/lib/jekyll/converters/scss.rb:3:in `require'
/Users/runner/work/www.ruby-lang.org/www.ruby-lang.org/vendor/bundle/ruby/2.7.0/gems/jekyll-sass-converter-2.0.1/lib/jekyll/converters/scss.rb:3:in `<top (required)>'
/Users/runner/work/www.ruby-lang.org/www.ruby-lang.org/vendor/bundle/ruby/2.7.0/gems/jekyll-sass-converter-2.0.1/lib/jekyll-sass-converter.rb:4:in `require'
/Users/runner/work/www.ruby-lang.org/www.ruby-lang.org/vendor/bundle/ruby/2.7.0/gems/jekyll-sass-converter-2.0.1/lib/jekyll-sass-converter.rb:4:in `<top (required)>'
/Users/runner/work/www.ruby-lang.org/www.ruby-lang.org/vendor/bundle/ruby/2.7.0/gems/jekyll-4.0.0/lib/jekyll.rb:206:in `require'
/Users/runner/work/www.ruby-lang.org/www.ruby-lang.org/vendor/bundle/ruby/2.7.0/gems/jekyll-4.0.0/lib/jekyll.rb:206:in `<top (required)>'
/Users/runner/work/www.ruby-lang.org/www.ruby-lang.org/vendor/bundle/ruby/2.7.0/gems/lanyon-0.4.1/lib/lanyon.rb:7:in `require'
/Users/runner/work/www.ruby-lang.org/www.ruby-lang.org/vendor/bundle/ruby/2.7.0/gems/lanyon-0.4.1/lib/lanyon.rb:7:in `<top (required)>'
/Users/runner/work/www.ruby-lang.org/www.ruby-lang.org/Rakefile:21:in `require'
/Users/runner/work/www.ruby-lang.org/www.ruby-lang.org/Rakefile:21:in `block in <top (required)>'
/Users/runner/work/www.ruby-lang.org/www.ruby-lang.org/vendor/bundle/ruby/2.7.0/gems/rake-13.0.0/exe/rake:27:in `<top (required)>'
/Users/runner/.rubies/ruby-2.7.2/bin/bundle:23:in `load'
/Users/runner/.rubies/ruby-2.7.2/bin/bundle:23:in `<main>'
Tasks: TOP => test => build
(See full trace by running task with --trace)
Error: Process completed with exit code 1.

It started breaking since October 6.

Cheers.

Add Ruby 2.1 support

I'd like to test a gem on Ruby 2.1 to ensure legacy compatibility. I understand that this Ruby version is not supported upstream anymore (as is Ruby 2.2). However, since Ruby 2.1 was shipped with some older operating systems (notably Debian 8 Jessie), I'd still like to support it with my code if possible, and obviously need to test this.

In fact, adding support to ruby/setup-ruby is rather straight forward. I have a WIP branch for that at meineerde/setup-ruby@feature/ruby-2.1. For Windows builds, this alone is enough. For macOS and Ubuntu, there would still need to be builds generated in ruby/ruby-builder.

Is this something you would be interested in?

Reading version from `.ruby-version` and Windows support

What is the best way of reading ruby version from .ruby-version file?

Something like:

      - uses: eregon/use-ruby-action@master
        with:
          ruby-version: "$(cat .ruby-version)" # or similar

Also, I didn't want to open an another issue for this but do you plan to support Windows? It would be awesome if we can get the windows builds. Windows support is live. Thank you.

Consider pulling bundler version from lock file

The support for using .ruby-version instead of having to supply it directly is so nice. Thanks!

Would you consider doing something similar with the bundler version from Gemfile.lock?

BUNDLED WITH
   2.1.4

It's not a huge deal to install the version the project is using manually, but when I saw how nicely you made the ruby version work I figured it was worth considering to make this super simple to use in a nearly drop in and run way for many projects.

Either way, thanks so much for this Action!

setup-ruby removes chocolatey from PATH

See trivial workflow that reproduces the problem: https://github.com/slonopotamus/asciidoctor-diagram/runs/434520900?check_suite_focus=true

Before setup-ruby actions is called, there's C:\ProgramData\Chocolatey\bin on PATH. But it is gone after setup-ruby is called.

For the reference, here's workflow file:

name: CI
on: [push, pull_request]
jobs:
  test:
    runs-on: windows-latest
    steps:
      - run: |
          echo "Before setup-ruby"
          $Env:Path
          choco --version
      - uses: ruby/setup-ruby@v1
        with:
          ruby-version: 2.7
      - run: |
          echo "After setup-ruby"
          $Env:Path
          choco --version

JRuby - "JRUBY_HOME or JRUBY_PARENT_CLASSPATH are not set"

While working on Puma, JRuby, and Ubuntu 20.04, it wouldn't compile. Might the following msg indicate an issue?

"JRUBY_HOME or JRUBY_PARENT_CLASSPATH are not set"

I don't know, but you'd know in your sleep...

See: https://github.com/MSP-Greg/puma/runs/1083079974?check_suite_focus=true#step:5:15

`jruby` and `bundler-cache: true` not playing nicely together

It's possible I'm doing something wrong, but I just tried using the bundler-cache: true option and found that it works fine for MRI rubies but for jruby it runs bundle install fine, but then when we run bundle exec rspec we get:

bundler: failed to load command: rspec

(rspec is in the Gemfile.) What am I missing?

jruby fails on windows-2016

Found as part of #60, the three jruby versions fail on windows-2016 because tar is not at the expected place

Question - do I need to update the action name?

I saw this in the README:

Note: this action used to be at eregon/use-ruby-action and was moved to the ruby organization.

I have a running project using eregon/use-ruby-action@v1. Do I need to update it to ruby/setup-ruby@v1?

Any possibility for ARM (Raspberry Pi) support?

I found that setup-ruby downloads an x86 binary when run on a Raspberry Pi self-hosted runner. Is there a way to add ARM binaries here or to ruby-builder?

Ruby 2.3.8 not available on Windows

I noticed it when seeing this error (fantastic, clear, error message, by the way, kudos to that).

Not sure if it's expected or not.

If it's expected, a note should probably be added to the README like the one for ruby 2.2:

Ruby 2.2 resolves to 2.2.6 on Windows (last build from RubyInstaller) and 2.2.10 otherwise.

If it's not expected, can we add 2.3.8 for Windows? :)

Suggestion: new 'github-pages' value for 'ruby-version'

This is a request similar to actions/setup-ruby#86: it would've been great if we could specify Ruby version that is currently used by the GitHub's github-pages gem:

      - uses: ruby/setup-ruby@v1
        with:
          ruby-version: 'github-pages'

It can be extracted from https://pages.github.com/versions/ or https://pages.github.com/versions.json

Providing ruby-head builds

@MSP-Greg, @larskanis (#10 (comment)) and @ioquatix (actions/setup-ruby#44 (comment)) have already mentioned interest in this.

I recently added support for truffleruby-head so it shouldn't be too hard.

Current plan is:

• https://github.com/eregon/ruby-dev-builder builds for Ubuntu & macOS
• Use https://github.com/oneclick/rubyinstaller2/releases/tag/rubyinstaller-head for Windows

Cannot find bundler for Ruby 2.7.0

# .github/workflows/build.yml
name: Build

on: [push, pull_request]

jobs:
  build:
    runs-on: ubuntu-latest
    env:
      RAILS_ENV: test
    services:
      postgres:
        image: postgres:12.0
        env:
          POSTGRES_USER: postgres
          POSTGRES_PASSWORD: "postgres"
          POSTGRES_DB: postgres
        ports:
          - 5432/tcp
        # needed because the postgres container does not provide a healthcheck
        options: --health-cmd pg_isready --health-interval 10s --health-timeout 5s --health-retries 5

    steps:
      - uses: actions/checkout@v2
        with:
          fetch-depth: 1

      - name: apt-get
        run: |
          sudo apt-get update -y
          sudo apt-get install -y libpq-dev postgresql-client

      - name: Set up Ruby
        uses: ruby/setup-ruby@v1
        with:
          ruby-version: 2.7

      - name: Cache gems
        uses: actions/cache@v1
        with:
          path: vendor/bundle
          key: bundle-use-ruby-${{ hashFiles('.ruby-version') }}-${{ hashFiles('**/Gemfile.lock') }}
          restore-keys: |
            bundle-use-ruby-${{ hashFiles('.ruby-version') }}-
      - name: bundle install
        run: |
          bundle config path vendor/bundle
          bundle install --jobs 4 --retry 3

      - name: Setup database
        run: bin/rails db:create db:migrate

      - name: RSpec
        run: bundle exec rspec

Error

Run bundle config path vendor/bundle
/home/runner/.rubies/ruby-2.7.0/lib/ruby/2.7.0/rubygems.rb:275:in `find_spec_for_exe': Could not find 'bundler' (1.17.3) required by your /home/runner/work/JuanitoFatas/JuanitoFatas/Gemfile.lock. (Gem::GemNotFoundException)
To update to the latest version installed on your system, run `bundle update --bundler`.
To install the missing version, run `gem install bundler:1.17.3`
	from /home/runner/.rubies/ruby-2.7.0/lib/ruby/2.7.0/rubygems.rb:294:in `activate_bin_path'
	from /home/runner/.rubies/ruby-2.7.0/bin/bundle:23:in `<main>'
[error]Process completed with exit code 1.

Any idea how may I help to resolve this? 🤔

Bundler cache mechanism not as efficient as with setup-rbenv method

Hi there, I was previously using https://github.com/masa-iwasaki/setup-rbenv from @masa-iwasaki and the bundler cache method from: https://github.com/actions/cache/blob/master/examples.md#ruby---gem

After switching to use-ruby-action then the bundler cache seems to never be read.

Here's my full workflow: https://gist.github.com/vvo/5f7b8a1d34d5efc2df18140fb1d3ed20

Bundle install always takes multiple minutes while previously it was taking 10s. Any idea what could be wrong?