bundler: <version> is not respected

[pboling]

This workflow should be using a specified version of bundler, in this case 1.16.6, but instead it attempts an install of ~> 1.0, seemingly ignorant of the configuration.
The install attempted is the same command as in #326, which is very sus.

/opt/hostedtoolcache/Ruby/2.2.10/x64/bin/gem install bundler -v ~> 1.0

Result:

Installing Bundler
  Bundler 2 requires Ruby 2.3+, using Bundler 1 on Ruby <= 2.2
  /opt/hostedtoolcache/Ruby/2.2.10/x64/bin/gem install bundler -v ~> 1.0
  ERROR:  Error installing bundler:
  	"bundle" from bundler conflicts with /opt/hostedtoolcache/Ruby/2.2.10/x64/bin/bundle
  Took   0.66 seconds
Error: Error: The process '/opt/hostedtoolcache/Ruby/2.2.10/x64/bin/gem' failed with exit code 1
    at ExecState._setResult (/home/runner/work/_actions/ruby/setup-ruby/v1/dist/index.js:3454:25)
    at ExecState.CheckComplete (/home/runner/work/_actions/ruby/setup-ruby/v1/dist/index.js:3437:18)
    at ChildProcess.<anonymous> (/home/runner/work/_actions/ruby/setup-ruby/v1/dist/index.js:3331:27)
    at ChildProcess.emit (events.js:314:20)
    at maybeClose (internal/child_process.js:1022:16)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:287:5)

[MSP-Greg]

There was some discussion about adding a rubygems input and its effect on the bundler input. Or, using both may not be a good idea.

Hence, for now, I suspect you'd be best to use 'none' for the bundler input...

[eregon]

bundler: none will however not use bundler-cache even if it's set, because bundler: none means "I don't need Bundler".

The error itself is most likely a bug of that RubyGems version, it should allow to install bundler 1 (again) fine.

I guess we could skip installing bundler if the rubygems input is set, and the bundler input is default.

@deivid-rodriguez Do all versions of RubyGems install Bundler as well on gem update --system [VERSION], and are they all careful to e.g. not install Bundler 2 on a old Rubies which can't use it?

[eregon]

My previous reply applies mostly to #326, I thought it was the same issue but renamed.

For the issue that the given Bundler version is ignored here, that's a clear bug.

[pboling]

@eregon @deivid-rodriguez - some ruminations:

After I made these issues it occurred to me that there are multiple ways of interpreting bundler: default -

1. Use whatever came with rubygems
2. Use whatever came with Ruby
3. Use whatever came with docker image, or whatever was pre-existing.
4. Install and use the "default" value that rubygems comes up with based on its parsing of RUBY_VERSION when executing gem install bundler with no version constraint. Rubygems will install the most recent bundler that is compatile with RUBY_VERSION.

None of these are happening when default is specified, but I would posit that all options are useful.

bundler: none does have a similar effect to Option 1 above, except, as @eregon pointed out, it prevents bundler-cache from being used.

bundler: latest has the effect of option 4.

So perhaps there are more terms, and implementation, needed to give the various options people would want.

[deivid-rodriguez]

@deivid-rodriguez Do all versions of RubyGems install Bundler as well on gem update --system [VERSION], and are they all careful to e.g. not install Bundler 2 on a old Rubies which can't use it?

Regarding the first question, not sure, this behavior was there even before I started maintaining RubyGems and Bundler, but I can't tell exactly when it was first introduced without checking. Regarding the second question, yes, it should always install a compatible version.

[eregon]

@pboling bundler: default is defined here:

setup-ruby/action.yml

Line 23 in e404913

Defaults to 'Gemfile.lock' if the file exists and 'latest' otherwise.

Since updating RubyGems also installs Bundler, I think we can just skip installing Bundler in that case, if bundler: default, but still allow using bundler-cache.

Maybe a new value to mean "use the bundler already installed (from Ruby or RubyGems update)" makes sense, it would be like none but allow bundler-cache, and maybe fail if there is no bundler installed. Not sure it's really needed though. Not sure of a good name for it either.

[MSP-Greg]

Do all versions of RubyGems install Bundler

A quick check, looks like Bundler is only installed for gem update --system 2.6 and later. 2.6.14 works with Rubies >= 1.8.7

Maybe a new value to mean "use the bundler already installed (from Ruby or RubyGems update)" makes sense, it would be like none but allow bundler-cache, and maybe fail if there is no bundler installed. Not sure it's really needed though. Not sure of a good name for it either.

Maybe 'rubygems' which disables bundler installation (and defaults to the Bundler version installed?

[pboling]

Proposal: Additional Options

I propose additional options, and making "default" synonymous with one of them, such that the complete set of options is as follows:

option	bundler-cache available	gem install	description
"rubygems"	yes	no	Use what came with Rubygems, if any
"ruby"	yes	no	Use what came with Ruby, if any
"system"	yes	no	Use what came with docker image / system, if any
"latest"	yes	gem install bundler (no version constraint)	* perhaps the logic driving current ~> 1 constraint
"Gemfile.lock"	yes	gem install bundler -v <version parsed from Gemfile.lock>	use whatever is specified in Gemfile.lock
<version number>	yes	gem install bunder -v <version number>	Use specified version number
"none"	no	no	NOOP

* are there bugs in bundler gem's minimum ruby requirement that necessitate the current ~> 1 logic?

Which one would be best as synonymous with default?

Since it doesn't do what I consider intuitive for "default" currently, I think it would be a breaking change regardless, for some action workflows currently using "default".

I agree with @MSP-Greg, I think a switch to having default be synonymous with rubygems is the closest to the principle of least surprise. This is what I was expecting it to do originally.

[MSP-Greg]

1. Maybe it's time to consider a jump to v2.

2. The 'bundler-cache' input defaults to false, and the only other allowed value is true. So, it can be independent of the other inputs, and if one runs bundle install without a copy of Bundler, it errors.

3. Rather than adding multiple inputs to the 'bundler' input, maybe the following:

   • Add a 'noop' input, which forces 'don't install bundler' (using the default version or the one installed by gem update --system)
   • If the 'rubygems' input is specified and a 'bundler' input is not, Bundler will be installed if a file/ENV specifies its version, otherwise no install of Bundler will occur.
   • If a numeric version or latest is specified for 'bundler', it will be installed, regardless of the 'rubygems' input value.
   • Remove none as an allowed value for the 'bundler' input.
   • I'm not sure if the input value of Gemfile.lock is needed for the 'bundler` input. Should it be automatic if the info is specified?

[eregon]

1. No, it's too annoying to update to a major version and this is an edge case/small bug (rubygems input didn't exist for long)
2. True, bundler-cache could always be decided independently of the bundler input, given the current default of false (and probably unlikely to change)
3. I don't think we need to add anything currently, it would only make things more complicated

I agree with @MSP-Greg, I think a switch to having default be synonymous with rubygems is the closest to the principle of least surprise. This is what I was expecting it to do originally.

No, because then it could pick a wrong Bundler version, or force installing yet another Bundler version at runtime when there is a lockfile.
And almost all workflows need Bundler, so no bundler by default for Ruby < 2.6 makes no sense.
I believe the default behavior is already what 99% want, and we have no need to change that.

We just need to fix the interaction of the rubygems, bundler and bundler-cache inputs, I'll do that when I get some time.

[eregon]

I forgot but bundler-cache is already independent of the bundler input since fabf251.
So bundler: none should work for your use-case here @pboling.
And setting rubygems should affect bundler: default to behave like bundler: none in that case.