Can't install latest bundler for a specific minor version (e.g. 2.2.x)

[Fryguy]

Let's say I want to install the latest bundler 2.2.x.

• If I pass bundler: 2.2, then it installs 2.3.x because it generates the command gem install bundler -v ~> 2.2
• if I pass bundler: 2.2.0, then it installs 2.2.0, and not the latest, because it generates the command gem install bundler -v 2.2.0.
• If I pass bundler: 2.2.x that is not valid input into the gem install command.
• I've also tried mangling the input in various ways to bypass the regex that gates the ~>, but those are detected as invalid input.

If there is no workaround, then this is an enhancement request to perhaps allow something like bundler: 2.2.x, which, if detected, would translate to gem install bundler -v ~> 2.2.0.

Example:

    - name: Set up Ruby
      uses: ruby/setup-ruby@v1
      with:
        ruby-version: ${{ matrix.ruby-version }}
        bundler: 2.2.x
        bundler-cache: true

[eregon]

Indeed.
I guess the interesting question is why do you want to pin to "2.2.x"?
The idea is in general people either only pin to a major version (e.g. 2), or to an exact version (e.g. 1.2.3) to avoid some issue/regression in some known Bundler release (and for that pinning to minor only seems not so useful).

cc @deivid-rodriguez

[Fryguy]

In my case I'm actually writing a bundler plugin, so I want to test against many different bundler versions (2.1.x, 2.2,x, etc). But even outside of my use case, I could see use cases where libraries might interact with bundler's API / classes, and want to make sure that new changes in a minor version don't break. Additionally, from a production standpoint, there are also cases where people don't want the latest minor, a la semver, until they've fully regression tested it, but they are comfortable with patch versions.

[MSP-Greg]

Part of the issue here is that almost all of the code is js, so duplicating RubyGems' version parsing would be a pita.

One option would be to pass the full bundler input string to the gem install command if it did not start with \d or matched 'none', 'latest', or 'Gemfile.lock'. So, if your input was '~> 2.2.0', that would be passed?

Wouldn't be a breaking change, and would allow for your use case?

[Fryguy]

Passing '~> 2.2.0' was one of the hacks I tried but was blocked by

setup-ruby/bundler.js

Line 68 in bd94d6a

if (/^\d+/.test(bundlerVersion)) {

I would be ok if that were the format we allowed, as it would be in line with my expectations.

I'm also not sure we need the entirety of rubygems version parsing, which is why I suggested '2.2.x' (as in \d+\.\d+\.x with a literal x at the end). That should be a fairly easy addition into the current logic.

[MSP-Greg]

Ther reason for my suggestion is that it would allow full implementation of RG's version constraints (like compound ones) without needing a special syntax that would need to be parsed/translated in js...

[eregon]

I think bundler: 2.2 should just work as you intend, and it seems fair to consider it a bug it would install 2.3 or so.
So let's fix that, and I think it can be as simple as checking if 1 or 2 numbers are given.
We'd pass "~> #{version}.0" to gem install.

Because ruby-version: 2.2 does work already like "latest 2.2.x". It does so by iterating all versions and finding the last one starting with that prefix, but we can't do that for Bundler.
I don't want any ".x" syntax for consistency.

[Fryguy]

Created a PR (#306) with the fix suggested by @eregon in #304 (comment)