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.
Native launcher appears to hang on GHA when the JDK version is too
old for JRuby 10. This bypasses it and should be a bit lighter. It
will also avoid any variability in the launcher used, since Unixes
and Windows already use different executables.
Apparently this exec errors when the subprocess fails rather than
returning an error code. This causes the whole setup process to
terminate. This patch catches the error and uses that to indicate
failure to launch.
* JRuby 10 requires Java 21. Since the previous default was 17 and all JRuby releases should work fine on 21, we do this for all JRuby installs.
* Implements #718
**What does this PR do?**
This PR provides the final piece of the puzzle to fix#682: now that
ruby-dev-builder is building `3.4-asan` Rubies since
https://github.com/ruby/ruby-dev-builder/pull/15, we can make them
available for use.
**Motivation:**
At Datadog, we're using ASan builds to check for issues
[in our library](https://github.com/datadog/dd-trace-rb),
and having a `3.4-asan` build improves the experience of having
these checks be a required CI step. Using the ASan builds built from
ruby-head means our CI could break because of unrelated issues/changes
from ruby-head.
**Additional Notes:**
`yarn` was trying really hard to update a bunch of things, which
generated A LOT of diff noise. I've manually pared them down just
to the actual changes related to adding the new variant so the
diff makes a bit more sense.
**How to test the change?**
I've already tested this in
https://github.com/DataDog/dd-trace-rb/actions/runs/13392865620/job/37696781848
and it seems to be working fine!
If set up `rubygems: latest` in workflow,
it will cause the error with Ruby 3.0 because the latest rubygems does not support Ruby 3.0.
Ref. https://rubygems.org/gems/rubygems-update
### Error message
```
Updating RubyGems
/opt/hostedtoolcache/Ruby/3.0.7/x64/bin/gem --version
3.2.33
Default RubyGems version is 3.2.33
Updating RubyGems to latest version
/opt/hostedtoolcache/Ruby/3.0.7/x64/bin/gem update --system
ERROR: Error installing rubygems-update:
rubygems-update-3.6.1 requires Ruby version >= 3.1.0. The current ruby version is 3.0.7.220.
ERROR: While executing gem ... (NoMethodError)
undefined method `version' for nil:NilClass
Updating rubygems-update
Took 2.86 seconds
Error: The process '/opt/hostedtoolcache/Ruby/3.0.7/x64/bin/gem' failed with exit code 1
```
### How to reproduce
```
uses: ruby/setup-ruby@v1
with:
ruby-version: "3.0"
rubygems: latest
```
* Remove the ASan Debugging section for now as it seems mostly redundant.
Native extensions are automatically compiled with ASan, so there is nothing special to do to use 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
When a fixed version is passed, it should be the minimum RubyGems
version for the whole matrix, i.e., RubyGems should not be dowgraded
past the default version of the oldest Ruby in the matrix.
* 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.
As described in the comment, due to a bug discussed on https://github.com/actions/runner/issues/849,
we currently have to use quotes for '3.0' as a workaround.
This change makes it easy for people not to remove quotes as they misunderstand it's a typo.
* This is a special case, because TruffleRuby needs an extra system
dependency that other Rubies do not, and GitHub runners do not have
these packages installed by default, while TravisCI has them.
envPreInstall - sets ENV values for runners
common.setupPath - collects all Path operations into one function, runs before Ruby install
Add MSYS2 paths to all Windows builds for MSYS2 Bash use
External actions may use setup-ruby, and some actions make changes/additions to the build environment. These may be needed for dependencies.
Hence, allow those external actions to run code before 'bundle install'. This is done by passing a function as a parameter to setupRuby().
1. common.js - add function win2nix(path) to convert windows style paths to nix style
2. ruby_builder.js - use Git tar for windows-2016, leave windows-2019 as is
* Avoid issues when using --conservative as seen in
https://github.com/ruby/setup-ruby/pull/48, clarifies what's getting
installed and simplifies the following logic.
* We'll probably need changes when Bundler 3 comes out anyway.
1. Use 'Git for Windows' cert.pem file
2. Add MSYS2 to path for mswin (after msvc additions)
3. Rearrange code for cleanup when MSYS2 is added to Window image
The jruby-launcher needs to be tested at least one major JRuby version back. In addition, there are users out there running JRuby 9.1.x that may be unable to upgrade at present.
* It was 40 checks and a lot of queuing on macOS.
* Version parsing is stable and can be tested more directly.
* 2.6.5 was tested twice: .ruby-version and explicitly.
* That way it's always perfectly synchronized with the action. In
practice querying another repository sometimes returned a stale copy.
* Avoids an extra HTTPS request.
* The axios dependency is no longer needed.
* Makes it possible to tweak the versions available according to the platform.
First, take some time to think whether this is really an issue of ruby/setup-ruby and whether it is fixable in this action.
This action basically just downloads a prebuilt Ruby and adds it to `PATH`, so it is unlikely the bug is in this action.
Give some thoughts whether it could be an issue in your workflow, in the gems you use, in GitHub Actions, in Ruby, RubyGems, Bundler, etc.
This is NOT the place to ask help about your workflow failing (ask that on [GitHub Community](https://github.com/orgs/community/discussions/categories/actions) or [Discussions](https://github.com/ruby/setup-ruby/discussions) instead), it is only to report issues about ruby/setup-ruby.
Please note we will close your issue without comment if you do not fill out the requested information.
- type:checkboxes
attributes:
label:Ensure the following before filing this issue
options:
- label:|
I verified it reproduces with the latest version with `- uses: ruby/setup-ruby@v1` (see [Versioning policy](https://github.com/ruby/setup-ruby/blob/master/README.md#versioning))
required:true
- label:|
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)
required:true
# - label: |
# If the issue happens on JRuby or TruffleRuby, and does not happen on CRuby (please check), file an issue there instead. It's very unlikely ruby/setup-ruby is the cause.
# required: true
- type:dropdown
attributes:
label:Are you running on a GitHub-hosted runner or a self-hosted runner?
options:
- GitHub-hosted runner
- self-hosted runner
validations:
required:true
- type:input
attributes:
label:Link to the failed workflow job (must be a public workflow job, so the necessary information is available)
This action downloads a prebuilt ruby and adds it to `$PATH`.
This action downloads a prebuilt ruby and adds it to the `PATH`.
It currently supports the latest stable versions of MRI, JRuby and TruffleRuby.
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.
See https://github.com/eregon/ruby-install-builder/blob/metadata/versions.json
for the available Ruby versions.
**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](#versioning).
The action works for the `ubuntu-16.04`, `ubuntu-18.04` and `macos-latest` GitHub-hosted runners.
`windows-latest` is not yet supported.
### Supported Versions
The prebuilt rubies are generated by https://github.com/eregon/ruby-install-builder.
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.5.0-preview1, head, debug, mingw, mswin, ucrt |
| `jruby` | 9.1.17.0 - 10.0.2.0, head |
| `truffleruby` | 19.3.0 - 24.2.1, head |
| `truffleruby+graalvm` | 21.2.0 - 24.2.1, head |
`ruby-debug` is the same as `ruby-head` but with assertions enabled (`-DRUBY_DEBUG=1`).
`ruby-asan` is the same as `ruby-head` but with AddressSanitizer (ASan) enabled, helpful for finding memory issues in native extensions.
Native extensions are automatically compiled with AddressSanitizer when using `ruby-asan`.
`ruby-asan` is currently only available on `ubuntu-24.04`.
`ruby-3.4-asan` is similar to `ruby-asan` but built from the latest stable 3.4 release tag.
Like `ruby-asan`, it's currently only available on `ubuntu-24.04`.
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](https://rubyinstaller.org/downloads/archives/)
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](https://docs.github.com/en/actions/reference/runners/github-hosted-runners) images. Runner images not listed below are not supported yet. `$OS-latest` just alias to one of these images.
and the [condition and expression syntax](https://help.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions).
### 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.5`)
* version only like `2.6.5`, assumes MRI for the engine
* engine only like `truffleruby`, uses the latest stable release of that implementation
* 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
*`mise.toml` reads from the project's `mise.toml` file
* If the `ruby-version` input is not specified, `.ruby-version` is tried first, followed by `.tool-versions`, followed by `mise.toml`
### All Stable Versions
### Working Directory
With that, we can test on all stable releases of MRI, JRuby and TruffleRuby with:
The `working-directory` input can be set to resolve `.ruby-version`, `.tool-versions`, `mise.toml` and `Gemfile.lock`
if they are not at the root of the repository, see [action.yml](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](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](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:
```yaml
name:My workflow
on:[push]
jobs:
test:
strategy:
fail-fast:false
matrix:
os:[ubuntu-latest, macos-latest ]
ruby:[2.4,2.5,2.6,2.7,truffleruby, jruby ]
runs-on:${{ matrix.os }}
steps:
- uses:actions/checkout@v2
- uses:eregon/use-ruby-action@master
- uses:ruby/setup-ruby@v1
with:
ruby-version:${{ matrix.ruby }}
- run:ruby -v
bundler-cache:true
```
## Efficiency
Note that any step doing `bundle install` (for the root `Gemfile`) or `gem install bundler` can be removed with `bundler-cache: true`.
It takes about 5 seconds to setup the given Ruby.
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`](#working-directory).
If there is a `Gemfile.lock` (or `$BUNDLE_GEMFILE.lock` or `gems.locked`), `bundle config --local deployment true` is used.
## Limitations
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](#matrix-of-gemfiles).
* Currently does not work on Windows since the builder doesn't build on Windows.
https://github.com/MSP-Greg/actions-ruby is an alternative on Windows.
* This action currently only works with GitHub-hosted runners, not private runners.
#### 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](#matrix-of-gemfiles).
To find the correct the environment variable name, see the [Bundler docs](https://bundler.io/man/bundle-config.1.html) 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.)
```yaml
- 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](https://github.com/ruby/setup-ruby/issues/209#issuecomment-889064123)) 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](https://help.github.com/en/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#using-a-specific-shell).
This can lead issues such as multi-line scripts [not working as expected](https://github.com/ruby/setup-ruby/issues/13).
* The `PATH` contains [multiple compiler toolchains](https://github.com/ruby/setup-ruby/issues/19). 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](https://github.com/ruby/setup-ruby/issues/18#issuecomment-889072695)).
* JRuby on Windows has multiple issues ([jruby/jruby#7106](https://github.com/jruby/jruby/issues/7106), [jruby/jruby#7182](https://github.com/jruby/jruby/issues/7182)).
* When compiling extension code, note that the packages required to build Ruby are included when using Windows 2022. Additional packages can be installed with [setup-ruby-pkgs](https://github.com/ruby/setup-ruby-pkgs) or via MSYS2's `pacman`. These packages may be required when installing or updating Ruby stdlib extension gems.
## 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](https://github.com/actions/toolkit/blob/master/docs/action-versioning.md) of GitHub Actions.
## Using self-hosted runners
This action might work with [self-hosted runners](https://docs.github.com/en/actions/hosting-your-own-runners/about-self-hosted-runners)
if the [Runner Image](https://github.com/actions/runner-images) 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`](https://stackoverflow.com/questions/26555902/ruby-v-dyld-library-not-loaded-usr-local-lib-libgmp-10-dylib) 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](action.yml).
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](https://github.com/ruby/setup-ruby/releases/tag/v1.13.0) 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.
description:'Download a prebuilt Ruby and add it to $PATH in 5 seconds'
description:'Download a prebuilt Ruby and add it to the PATH in 5 seconds'
author:'Benoit Daloze'
branding:
color:red
icon:download
inputs:
ruby-version:
description:'Engine and version to use in the format "myruby-X.Y.Z"'
required:true
description:'Engine and version to use, see the syntax in the README. Reads from .ruby-version, .tool-versions or mise.toml if unset.'
default:'default'
rubygems:
description:|
The version of RubyGems to use. Either 'default' (the default), 'latest', or a version number (e.g., 3.3.5).
For 'default', no action is taken and the version of RubyGems that comes with Ruby by default is used.
For 'latest', `gem update --system` is run to update to the latest compatible RubyGems version.
Ruby head/master builds will not be updated.
Similarly, if a version number is given, `gem update --system <version>` is run to update to that version of RubyGems, as long as that version is newer than the one provided by default.
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.
bundler-cache:
description:'Run "bundle install", and cache the result automatically. Either true or false.'
default:'false'
working-directory:
description:'The working directory to use for resolving paths for .ruby-version, .tool-versions, mise.toml and Gemfile.lock.'
cache-version:
description:|
Arbitrary string that will be added to the cache key of the bundler cache. Set or change it if you need
to invalidate the cache.
self-hosted:
description:|
Consider the runner as a self-hosted runner, which means not using prebuilt Ruby binaries which only work
on GitHub-hosted runners or self-hosted runners with a very similar image to the ones used by GitHub runners.
The default is to detect this automatically based on the OS, OS version and architecture.
windows-toolchain:
description:|
This input allows to override the default toolchain setup on Windows.
The default setting ('default') installs a toolchain based on the selected Ruby.
Specifically, it installs MSYS2 if not already there and installs mingw/ucrt/mswin build tools and packages.
It also sets environment variables using 'ridk' or 'vcvars64.bat' based on the selected Ruby.
At present, the only other setting than 'default' is 'none', which only adds Ruby to PATH.
No build tools or packages are installed, nor are any ENV setting changed to activate them.
File diff suppressed because it is too large
Load Diff
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.