After upgrade from v0.0.5 to v1.0.0 Github Actions flow broke

[giedriusr]

Hello,

Upgrading the gem from 0.0.5 => 1.0.0 broke our flow.
After investigating your action.yml file I see that it points to "ruby" which probably uses the newest ruby version out there:
https://github.com/standardrb/standard-ruby-action/blob/main/action.yml#L16

In our case, we have .ruby-version file, where we defined 3.2.2 and also insige Gemfile. Ruby Linter flow doesn't take into consideration. Ruby version mismatch causes the failure of Github Actions.

# Github Action output

3s
Run standardrb/[email protected]
Run actions/checkout@v4
Syncing repository: repo_name
Getting Git version info
Temporarily overriding HOME='/home/runner/work/_temp/129298de-543e-4a88-9cd8-a967cb54b77b' before making global git config changes
Adding repository directory to the temporary git global config as a safe directory
/usr/bin/git config --global --add safe.directory /home/runner/work/repo
/usr/bin/git config --local --get remote.origin.url
https://github.com/repo_url
Removing previously created refs, to avoid conflicts
/usr/bin/git submodule status
Cleaning the repository
Disabling automatic garbage collection
Setting up auth
Fetching the repository
Determining the checkout info
/usr/bin/git sparse-checkout disable
/usr/bin/git config --local --unset-all extensions.worktreeConfig
Checking out the ref
/usr/bin/git log -1 --format='%H'
'xxx'
Run ruby/setup-ruby@v1
  with:
    ruby-version: ruby
    bundler-cache: true
  env:
    BUNDLE_GEMS__CONTRIBSYS__COM: ***
    BUNDLE_PACKAGER__DEV: ***
    GITHUB_TOKEN: ***

**Modifying PATH
  Entries removed from PATH to avoid conflicts with default Ruby:
    /opt/hostedtoolcache/Ruby/3.2.2/x64/bin
  Entries added to PATH to use selected Ruby:
    /opt/hostedtoolcache/Ruby/3.3.3/x64/bin**

Downloading Ruby
  https://github.com/ruby/ruby-builder/releases/download/toolcache/ruby-3.3.3-ubuntu-22.04.tar.gz
  Took   0.72 seconds

Extracting  Ruby
Print Ruby version
Installing Bundler
> bundle install
/opt/hostedtoolcache/Ruby/3.3.3/x64/bin/bundle config --local path /home/runner/work/repo/vendor/bundle
/opt/hostedtoolcache/Ruby/3.3.3/x64/bin/bundle config --local deployment true
Cache key: setup-ruby-bundler-cache-v6-ubuntu-22.04-x64-ruby-3.3.3-wd-/home/runner/work/repo-with--without--only--Gemfile.lock-d993edc49f671b570cdd3540c33f2702ba7086b1494b50e1c2a245cf0a1369e0
/opt/hostedtoolcache/Ruby/3.3.3/x64/bin/bundle install --jobs 4
Your Ruby version is 3.3.3, but your Gemfile specified 3.2.2
Error: The process '/opt/hostedtoolcache/Ruby/3.3.3/x64/bin/bundle' failed with exit code 18

Our action.yml

name: Verify
on: [push]

jobs:
  linters:
    name: Linters
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Setup Ruby and install gems
        uses: ruby/setup-ruby@v1
        with:
          bundler-cache: true

      - name: StandardRB Linter
        uses: standardrb/[email protected]
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Is it a bug or something has to change with our Action file?

Thank you

[searls]

The truth is, I only half-understand how Actions works and like any CI specification, the feedback loops are too slow and the use cases are too diffuse to really get my arms around them for very long, even when I do.

For your specific case, I think you should be able to just remove the ruby/setup-ruby@v1 step, since 1.0 and later of this action includes it.

More generally, it would seem that an this action could define inputs as parameters users could set, and then one such input (say, rubyVersion) which would be the default for what we tell ruby/setup.

[cirdes]

I had the same issue, and setting the rubyVersion as input fixed it. However, it’s strange—I was expecting it to automatically detect the Ruby version from my .ruby-version file.

- name: Standard Ruby
  uses: standardrb/standard-ruby-action@v1
  with:
    ruby-version: "3.2.5"

[searls]

Standard doesn't read from .ruby-version / .tool-versions / Gemfile's ruby because it's very possible you want to target an older source compatibility than you're running yourself. I develop all my gems against ruby-head, for example, but keep source-compat with Standard at whatever the oldest not-EOL'd Ruby is.

[searls]

I should say, though, that I'd accept a PR to either this action or to standard that set that target ruby version to whatever the conventional dotfile stipulates only if it's older than the latest resolvable ruby