Honor `BUNDLE_LOCKFILE` (added in Bundler 4) when selecting the lockfile used
for Bundler version detection, deployment mode, and bundler-cache keys. Without
this, workflows using an alternate lockfile can read the wrong `BUNDLED WITH`
version and generate cache keys from the wrong lockfile.
* As https://nodejs.org/api/os.html#oscpus says:
os.cpus().length should not be used to calculate the amount of parallelism available to an application. Use os.availableParallelism() for this purpose.
The number of jobs should scale with the runner CPU count, up to a
point. The bottleneck becomes network / disk I/O at very large numbers,
and 8 seems like a reasonable maximum based on my experience at this
time.
Currently, the lockfile gets printed after `bundle install` finished. This could be too late when `bundle install` fails for whatever reason.
I have a workflow that failed like this:
<details><summary>Logs</summary>
<p>
```
55s
Run ruby/setup-ruby@v1
Modifying PATH
Downloading Ruby
Extracting Ruby
Print Ruby version
Installing Bundler
> bundle install
/opt/hostedtoolcache/Ruby/2.7.8/x64/bin/bundle config --local path /home/runner/work/rubocop/rubocop/vendor/bundle
/opt/hostedtoolcache/Ruby/2.7.8/x64/bin/bundle lock
Fetching source index from https://rubygems.org/
Network error while fetching
https://rubygems.org/quick/Marshal.4.8/asciidoctor-0.0.1.gemspec.rz (Connection
reset by peer - SSL_connect)
Error: The process '/opt/hostedtoolcache/Ruby/2.7.8/x64/bin/bundle' failed with exit code 17
Run ruby/setup-ruby@v1
Modifying PATH
Downloading Ruby
Extracting Ruby
Print Ruby version
Installing Bundler
> bundle install
/opt/hostedtoolcache/Ruby/2.7.8/x64/bin/bundle config --local path /home/runner/work/rubocop/rubocop/vendor/bundle
/opt/hostedtoolcache/Ruby/2.7.8/x64/bin/bundle lock
Fetching source index from https://rubygems.org/
Network error while fetching
https://rubygems.org/quick/Marshal.4.8/asciidoctor-0.0.1.gemspec.rz (Connection
reset by peer - SSL_connect)
Error: The process '/opt/hostedtoolcache/Ruby/2.7.8/x64/bin/bundle' failed with exit code 17
```
</p>
</details>
It would help to print the lockfile for this I think. It fetching version 0.0.1 confused me but probably the lockfile looks ok. New output:
```
Run ./
Modifying PATH
Print Ruby version
Installing Bundler
> bundle install
/opt/hostedtoolcache/Ruby/3.2.9/x64/bin/bundle config --local path /home/runner/work/setup-ruby/setup-ruby/vendor/bundle
/opt/hostedtoolcache/Ruby/3.2.9/x64/bin/bundle lock
Fetching gem metadata from https://rubygems.org/...........
Resolving dependencies...
Writing lockfile to /home/runner/work/setup-ruby/setup-ruby/gemfiles/rails8.gemfile.lock
Print lockfile
Cache key: setup-ruby-bundler-cache-v6-ubuntu-24.04-x64-ruby-3.2.9-wd-/home/runner/work/setup-ruby/setup-ruby-with--without--only--/home/runner/work/setup-ruby/setup-ruby/gemfiles/rails8.gemfile.lock-cb69172094f71f01e5207070d9af8d465d9aa9c386ecbad22b1b6e8e43523fd2
/opt/hostedtoolcache/Ruby/3.2.9/x64/bin/bundle install --jobs 4
...
```
So it's relatively at the top and not hidden somewhere. Also removes the need to check for the lockfile again.
It was originally added by https://github.com/ruby/setup-ruby/pull/253,
in order to fix CI. However, now CI passes without it so I assume this
was fixed by rubyinstaller2.
Force actually bypasses dependency constraints so it's actually
installing the latest Bundler in a version of Ruby that's incompatible
with it.
* And give instructions for that case.
* Get the OS and OS version ourselves since some users set ImageOS incorrectly.
* This partially reverts commit ad1ebae995.
If passed `bundler: 2.2`, setup-ruby would install bundler 2.3, because
it would generate a constraint that looks like `~> 2.2`. This
unexpectedly installs the latest of the 2.x series, but the expectation
is that it would install the latest of the 2.2.x series.
Fixes#304
* On Windows there are no 64-bit builds of Ruby 1.9.
* Fix floatVersion() for head versions.
* Use floatVersion() in more cases instead of regexps.
* Rely on ~/.gemrc to not install gem docs.
Thomas Countz