setup-ruby fails when Gemfile.lock has BUNDLED WITH 2.4.0.dev

[Ishotihadus]

Ensure the following before filing this issue

• I verified it reproduces with the latest version with - uses: ruby/setup-ruby@v1 (see Versioning policy)

• I tried to reproduce the issue locally by following the workflow steps (including all commands done by ruby/setup-ruby, except for Downloading Ruby & Extracting Ruby),
  and it did not reproduce locally (if it does reproduce locally, it's not a ruby/setup-ruby issue)

Are you running on a GitHub-hosted runner or a self-hosted runner?

GitHub-hosted runner

The workflow code or a link to the workflow file

https://github.com/Ishotihadus/ruby-workflow-test/blob/main/.github/workflows/test.yaml

Link to the log of a failed workflow job, or to a gist with the output

https://gist.github.com/Ishotihadus/ceeec53cc6d20c23c64583b501645a48

The command and output of the failing step

2022-11-06T07:45:48.3135172Z ##[group]Run ruby/setup-ruby@v1
2022-11-06T07:45:48.3135412Z with:
2022-11-06T07:45:48.3135602Z   ruby-version: head
2022-11-06T07:45:48.3135825Z   bundler-cache: false
2022-11-06T07:45:48.3136032Z ##[endgroup]
2022-11-06T07:45:48.4836313Z ##[group]Modifying PATH
2022-11-06T07:45:48.4844171Z Entries added to PATH to use selected Ruby:
2022-11-06T07:45:48.4845297Z   /home/runner/.rubies/ruby-head/bin
2022-11-06T07:45:48.4846285Z ##[endgroup]
2022-11-06T07:45:48.4891148Z ##[group]Downloading Ruby
2022-11-06T07:45:48.4892896Z https://github.com/ruby/ruby-dev-builder/releases/latest/download/ruby-head-ubuntu-20.04.tar.gz
2022-11-06T07:45:52.1860425Z Took   3.70 seconds
2022-11-06T07:45:52.1861220Z ##[endgroup]
2022-11-06T07:45:52.1861803Z ##[group]Extracting  Ruby
2022-11-06T07:45:52.1892131Z [command]/usr/bin/tar -xz -C /home/runner/.rubies -f /home/runner/work/_temp/4682d8d2-a326-46d7-99b3-f37ce4491baa
2022-11-06T07:45:52.6585264Z Took   0.47 seconds
2022-11-06T07:45:52.6586304Z ##[endgroup]
2022-11-06T07:45:52.6586848Z ##[group]Print Ruby version
2022-11-06T07:45:52.6600950Z [command]/home/runner/.rubies/ruby-head/bin/ruby --version
2022-11-06T07:45:52.6775890Z ruby 3.2.0dev (2022-11-05T14:18:32Z master 267452e6fe) [x86_64-linux]
2022-11-06T07:45:52.6785227Z Took   0.02 seconds
2022-11-06T07:45:52.6786068Z ##[endgroup]
2022-11-06T07:45:52.6788625Z ##[group]Installing Bundler
2022-11-06T07:45:52.6798535Z Using Bundler 2.4.0.dev from Gemfile.lock BUNDLED WITH 2.4.0.dev
2022-11-06T07:45:52.6799036Z Took   0.00 seconds
2022-11-06T07:45:52.6799681Z ##[endgroup]
2022-11-06T07:45:52.6887123Z ##[error]Error: Cannot parse bundler input: 2.4.0.dev
    at Module.installBundler (/home/runner/work/_actions/ruby/setup-ruby/v1/dist/index.js:115:11)
    at /home/runner/work/_actions/ruby/setup-ruby/v1/dist/index.js:69331:15
    at body (/home/runner/work/_actions/ruby/setup-ruby/v1/dist/index.js:306:20)
    at Object.<anonymous> (/home/runner/work/_actions/ruby/setup-ruby/v1/dist/index.js:3955:28)
    at Generator.next (<anonymous>)
    at /home/runner/work/_actions/ruby/setup-ruby/v1/dist/index.js:3706:71
    at new Promise (<anonymous>)
    at __webpack_modules__.2186.__awaiter (/home/runner/work/_actions/ruby/setup-ruby/v1/dist/index.js:3702:12)
    at Object.group (/home/runner/work/_actions/ruby/setup-ruby/v1/dist/index.js:3951:12)
    at Module.measure (/home/runner/work/_actions/ruby/setup-ruby/v1/dist/index.js:321:25)

Any other notes?

I think this is because bundler.js detect bundler version by /^\d+(?:\.\d+){0,2}$/.

setup-ruby/bundler.js

Line 98 in ece8276

if (/^\d+(?:\.\d+){0,2}$/.test(bundlerVersion)) {

Bundler is sometimes released under version numbers with suffix, and I think handling this problem is helpful.
https://rubygems.org/gems/bundler/versions

[eregon]

Thank you for the report. PR welcome.
EDIT: see comment below, it doesn't seem so simple.

[eregon]

The problem is 2.4.0.dev doesn't seem an actual release of Bundler.
It's not at https://rubygems.org/gems/bundler/versions and:

$ gem i bundler:2.4.0.dev
ERROR:  Could not find a valid gem 'bundler' (= 2.4.0.dev) (required by 'bundler' (2.4.0.dev)) in any repository

So even it we let this check accept it, gem install bundler:2.4.0.dev would fail right after.

ruby-head currently ships with a Bundler which reports:

$ bundle --version
Bundler version 2.4.0.dev

But that's basically a changing Bundler I guess.

How should we deal with this @deivid-rodriguez ?

A simple workaround is not using a dev version of Bundler to create your Gemfile.lock, or not check Gemfile.lock in (if that makes sense for your case), or use the bundler: input explicitly (see

setup-ruby/action.yml

Lines 17 to 23 in c4fe7bd

	bundler:
	description: |
	The version of Bundler to install. Either 'Gemfile.lock' (the default), 'default', 'latest', 'none', or a version number (e.g., 1, 2, 2.1, 2.1.4).
	For 'Gemfile.lock', the version of the BUNDLED WITH section from the Gemfile.lock if it exists. If the file or section does not exist then the same as 'default'.
	For 'default', if the Ruby ships with Bundler 2.2+ as a default gem, that version is used, otherwise the same as 'latest'.
	For 'latest', the latest compatible Bundler version is installed (Bundler 2 on Ruby >= 2.3, Bundler 1 on Ruby < 2.3).
	For 'none', nothing is done.

).

[deivid-rodriguez]

I guess allow parsing that kind of version and skip the gem install step if the parsed version is a dev version?

[eregon]

We cannot just skip the gem install, e.g, we need to install Bundler 2 on Ruby <= 2.6 for instance.
I guess we should interpret *.dev as bundler: default, i.e., ignoring the value in Gemfile.lock because it's not really usable.
There is the edge case of e.g. 1.2.3.dev but hopefully we can ignore that (otherwise we'd need to consider the major version of a dev version which seems rather messy).

[deivid-rodriguez]

I guess we should interpret *.dev as bundler: default, i.e., ignoring the value in Gemfile.lock because it's not really usable.

Not sure what bundler: default means, but my suggestion is to "do nothing" essentially.

If users are committing a Gemfile.lock with a development version of Bundler, I guess they should be responsible themselves for making sure a development version is available in CI, either by using a development Ruby too or by installing a development version of Bundler themselves?

That said, I'm sure you know what's best better, was just throwing out my naive opinion since you asked.

[deivid-rodriguez]

Just saw your approach. Ignoring it seems totally fine too 👍.

[eregon]

Thanks for the feedback :) I wasn't sure what that dev means if it was "dev version" (it is) or some kind of pre-release.

[Ishotihadus]

I confirmed it works. Thanks