Allow optionally refreshing existing cache entries.

[Lord-Kamina]

Description

By enabling an optional input, this feature allows users to update existing cache keys. The way this can be done is by using Octokit to send a request to the Github API to delete the matched cache. This then allows the key to be reused and the save step to operate as if there hadn't been a match in the first place.

Motivation and Context

Pretty much since forever, people have been asking for a way to update existing cache entries. As of now, the best alternative is to just create a slightly different key each time, which would rapidly consume space. #1093

How Has This Been Tested?

I have written tests to test the functionality. They:

Test the deleteCacheByKey function in three scenarios: A successful and an unsucessful request (using MSW to mock the Github API), as well as a real request to the API, which is expected to return a 401 error because it uses a bogus token.

Test the run function in the scenarios of refresh-cache being enabled, but not being provided an API token, as well as a successful scenario in which it would attempt to delete the existing cache, and then reupload it.

Screenshots (if appropriate):

Types of changes

• [ ] Bug fix (non-breaking change which fixes an issue)
• [x] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)
• [x] Documentation (add or update README or docs)

Checklist:

• [x] My code follows the code style of this project. (Or at least I think? I run both the lint and format scripts)
• [x] My change requires a change to the documentation.
• [x] I have updated the documentation accordingly.
• [x] I have read the CONTRIBUTING document.
• [x] I have added tests to cover my changes.
• [x] All new and existing tests passed.

[Lord-Kamina]

Due to the conflict in README., I just noticed I haven't updated the granular save action, will fix that now.

[cdce8p]

Personally, I'd love this option. However, just from working the the cache API myself I noticed permission issues with deleting cache entries. For example the normal pull_request trigger doesn't grant the required write access to the parent repo.

Unfortunately, that might be a dealbreaker with that approach.

[Lord-Kamina]

Personally, I'd love this option. However, just from working the the cache API myself I noticed permission issues with deleting cache entries. For example the normal pull_request trigger doesn't grant the required write access to the parent repo.

Unfortunately, that might be a dealbreaker with that approach.

I have tested it from a pull_request from the same repo, which works fine. I'd have to try it from a fork and see how it goes. It would make sense that maybe it won't work. However, is it a deal breaker? It should just report a warning and move on in that case.

EDIT: You can see exactly that outcome in here: https://github.com/Lord-Kamina/actions-cache-update/actions/runs/4144733484/jobs/7168158463

Now... there are few scenarios I can think of when you would want an external PR to be able to manipulate your existing cache. The main one would be a project developer doing work on their personal fork and then submitting it as a PR.

In this scenario, the limitation could likely be circumvented by using a PAT instead, no?

[Lord-Kamina]

I have rebased this on main, as well as corrected a couple errors and added a way to update an existing cache even if using the granular save action (uses a lookup to see if the key exists)

[Lord-Kamina]

Hey everyone... I've been using this branch pretty much since I posted it way back when, without many issues. I recently realized there was a bug in my logic and have corrected it, as well as updated and rebased it.

Is there any chance this could get merged now?

[Lord-Kamina]

Note: CI runs on my fork are all good except for some reason prettier is complaining but only on windows, which I can't reproduce because I'm on mac. The workflow logs don't really give details either as to what the issue actually is.

https://github.com/Lord-Kamina/always-upload-cache/actions/runs/13141274792/job/36668786025#annotation:5:13

[Lord-Kamina]

Once again, rebased onto the main branch, and I've also figured out what the issue was with the tests on my branch. Made some additional changes to how eslint and prettier were being invoked, and corrected all those errors.