Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Open
2 tasks done
BytewaveMLP opened this issue Oct 20, 2024 · 4 comments · May be fixed by #660
Open
2 tasks done

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

BytewaveMLP opened this issue Oct 20, 2024 · 4 comments · May be fixed by #660

Comments

@BytewaveMLP
Copy link

BytewaveMLP commented Oct 20, 2024 •
edited
Loading

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
@BytewaveMLP BytewaveMLP changed the title Cache keys are treated as case-sensitive Cache keys are treated as case-sensitive, but case is not preserved in all environments Oct 20, 2024
@BytewaveMLP BytewaveMLP mentioned this issue Oct 20, 2024
Open
@eregon
Copy link
Member

eregon commented Oct 20, 2024

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
Copy link
Member

eregon commented Oct 20, 2024

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
Copy link
Author

@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 BytewaveMLP linked a pull request Oct 21, 2024 that will close this issue
Open
@BytewaveMLP
Copy link
Author

BytewaveMLP commented Oct 21, 2024 •
edited
Loading

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Use case-insensitive key comparison for cache keys BytewaveMLP/setup-ruby
2 participants
@eregon @BytewaveMLP