Restoring bundler cache is not working in v1.144.1

[jacob-carlborg-apoex]

Ensure the following before filing this issue

• I verified it reproduces with the latest version with - uses: ruby/setup-ruby@v1 (see Versioning policy)

• 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)

Are you running on a GitHub-hosted runner or a self-hosted runner?

GitHub-hosted runner

The workflow code or a link to the workflow file

name: CI
on: [push]
concurrency:
  group: ${{ github.ref }}
  cancel-in-progress: true

jobs:
  bundle:
    runs-on: ubuntu-20.04
    steps:
      - uses: actions/checkout@v3

      - name: Install dependencies
        run: |
          sudo apt-get update -qq && sudo apt-get install -y --no-install-recommends \
            libxmlsec1-dev libxmlsec1-openssl wkhtmltopdf

      - name: Github setup
        run: |
          git config --global url."https://${{secrets.GH_ACCESS_TOKEN}}:x-oauth-basic@github.com/".insteadOf "git@github.com:"

      - uses: ruby/setup-ruby@v1.144.1
        with:
          bundler-cache: true

Link to the log of a failed workflow job, or to a gist with the output

https://gist.github.com/jacob-carlborg-apoex/370a6197d4f1f5102f0a8c5e44235179

The command and output of the failing step

> bundle install
/opt/hostedtoolcache/Ruby/2.7.2/x64/bin/bundle config --local path /home/runner/work/foobar/foobar/vendor/bundle
/opt/hostedtoolcache/Ruby/2.7.2/x64/bin/bundle config --local deployment true
Cache key: setup-ruby-bundler-cache-v5-ubuntu-20.04-x64-ruby-2.7.2-wd-/home/runner/work/foobar/foobar-with--without--Gemfile.lock-74395cbea7219758bf34c731625de123b8704e40d1e7f64d3d455f933b051a3f
/opt/hostedtoolcache/Ruby/2.7.2/x64/bin/bundle install --jobs 4
Fetching gem metadata from https://rubygems.org/.......

### Any other notes?

Everything worked fine with `v1.144.0` but starting with `v1.144.1` `ruby/setup-ruby` fails to restore the bundler cache. There's no error message. The cache is just not restored.

I suspect the issue is this PR: https://github.com/ruby/setup-ruby/pull/482. It updated the NPM package `@actions/cache` from `3.0.6` to `3.2.1`. [3.2.1](https://github.com/actions/cache/releases/tag/v3.2.1) introduced this change: https://github.com/actions/cache/pull/1039, which was reverted in the next version [3.2.2](https://github.com/actions/cache/releases/tag/v3.2.2) in https://github.com/actions/cache/pull/1049.

[maestromac]

This is also happening to me. Verified on two repositories.

[MSP-Greg]

@jacob-carlborg-apoex

setup/ruby uses https://github.com/actions/toolkit/blob/main/packages/cache/

You're mentioning https://github.com/actions/cache

Two different repos. One is an action just like this (what you mentioned, the other is a set of js functions that can be used by an action...

Regardless, I've got some recent CI that ran, let me have a look...

[krbullock]

I've verified on one of our repos (private, sorry) that locking the action to v1.144.0 restores the cache and proceeds to run successfully.

[MSP-Greg]

I've verified that the caches are not being used, looking thru the code now...

[MSP-Greg]

Can anyone see if MSP-Greg/setup-ruby@00-gem-cache works?

IOW, replace ruby/setup-ruby@v1 with MSP-Greg/setup-ruby@00-gem-cache.

I've been using it in CI in my Puma fork, first I locked @actions/cache to 3.1.4, and that failed, then I locked to 3.0.6, and that installed the caches.

Obviously, we need to determine what the issue is with 3.2.1, but in the meantime...

[krbullock]

@MSP-Greg I tested it in our repository (same one that I had locked to v1.144.0), and it restores the cache correctly.

[MSP-Greg]

@krbullock Thanks for checking...

[trevorkwhite]

+1 just confirming we are seeing this as well. We were looking for a 🚬 🔫 on build time increases. Thanks @MSP-Greg for jumping on locking the cache so we don't have to do it manually!

[jacob-carlborg-apoex]

setup/ruby uses actions/toolkit@main/packages/cache/
You're mentioning actions/cache

Right, my bad.

[vitobotta]

I've verified on one of our repos (private, sorry) that locking the action to v1.144.0 restores the cache and proceeds to run successfully.

Thanks, reverting to this version fixes the issue for me :)

[simi]

Could this be related to e6689b4? There is updated @actions/cache in yarn.lock.

update: seems addressed at #484 🙏

[r7kamura]

+1 for reporting this issue. I too have encountered this problem.

Although v1.144.1 can generate cache, it is necessary to reinstall gems whenever I try to reuse cache that was created in v1.144.1. I also observed a problem that sometimes causes a mysterious error when installing gems...

After switching to v1.144.0, the same problem reappeared when trying to use the cache generated by v1.144.1 with v1.144.0. So I switched to using the cache generated by v1.144.0 with v1.144.0, and the problem no longer occurs.

[eregon]

Could someone report this upstream at https://github.com/actions/toolkit/tree/main/packages/cache ?

[eregon]

Also I don't see a single public link to a workflow run here (if you have one, please post it), so it's quite hard to analyze the problem. I will make such a link required for future issues.

[bewuethr]

Here's a public run having the issue.

[bewuethr]

Could someone report this upstream at https://github.com/actions/toolkit/tree/main/packages/cache ?

Looks like actions/toolkit#1377 reports it, no?

[eregon]

Should be fixed in https://github.com/ruby/setup-ruby/releases/tag/v1.144.2.
Thank you @MSP-Greg for the PR and filing the upstream issue!

[MSP-Greg]

Some maybe bad news...

PR #485 fixes the issue with the current @actions/cache code. But, on the first run, all caches will be rebuilt and saved. After that, caches should be restored.

The fine print: Current code was passing an array to @actions/cache. @actions/cache was modifying that array, which caused problems when we used the array later. See also actions/toolkit#1378.