Cache keys are treated as case-sensitive, but case is not preserved in all environments

[BytewaveMLP]

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?

self-hosted runner

Link to the failed workflow job (must be a public workflow job, so the necessary information is available)

https://gist.github.com/BytewaveMLP/d747b0378456c975d5ad122740a7ae1c

Any other notes?

The attached log is a Gist as the workflow run is in a private repo, however the bug is illustrated regardless.

I'd like to preface this by saying this isn't a bug when running on GitHub Actions, but rather on the popular act runner. So by some measure, this bug should also be reported there as well. However, GitHub Actions caching infrastructure does seem to recognize keys of differing case as being identical, so I think there's a case for it being fixed here.

I'm working on setting up a CI runner on an install of Gitea, using their act_runner fork of act designed to emulate GitHub Actions. However, I seem to be running into issues where setup-ruby is finding and restoring from a matching cache key successfully, but still creating and uploading a new cache artifact every run (see the attached log). If my debugging is correct, this comes down to the fact that the returned cache key name from cache.restoreCache (captured here) does not reflect the same case as it was created with. This seems to in turn be due to a conscious choice within act to normalize cache keys to lowercase prior to storing and looking up. This deviates from the GitHub Actions behavior, which seems to be to perform lookups case-insensitively, but return input as-is.

As best as I can tell, due to the semantics of GitHub Actions' cache keys, it should be safe to normalize them to lowercase, both upon receiving them from cache.restoreCache and before populating the cache with cache.saveCache. This should not affect existing usages of setup-ruby, and should allow for the cache to function properly on Gitea act_runner instances without requiring significant changes to the latter.

Also reported to act: nektos/act#2497

[eregon]

So

setup-ruby/bundler.js

Line 212 in 7bae1d0

if (cachedKey !== key) {

could be a cause of what you see? How would you propose to workaround that, can you make a PR?

I wonder if this could be an issue of https://github.com/actions/toolkit/tree/main/packages/cache, first of all it doesn't seem to document keys are case-insensitive and it doesn't say anything about how they should be compared. But comparing is necessary since saving for an existing key gives an error.
Or maybe if it raises a specific error in that case we could catch that, could you look into that?

I do think it's overall an act incompatibility though, and this action is tested GitHub Actions, not on act. In fact act had some problem with a v1 branch IIRC and I think that's never been fixed. So maybe it doesn't really work on act anyway.

[eregon]

FWIW I think cache keys should be case-sensitive, because they might contain paths and such paths are case sensitive and the difference could matter, e.g. gemfile vs Gemfile on Linux.

[BytewaveMLP]

@eregon It's my understanding that GitHub Actions will save the case you input, but for the purposes of looking up a cache key, it will ignore case. So for example, if you write key A to the cache and restore with key a, you'll get artifact A back.

I'll try putting together a PR to test and confirm.

[BytewaveMLP]

I've opened #660 to try and address this. Looks like actions/cache has a function for this, but it's not exported in the accompanying Node package.

I do agree that the documentation around this is unfortunately quite lacking. However, based on observed behavior plus the fact actions/cache has this insensitive comparison function, I'm led to believe this is the correct approach.