Allow optionally refreshing existing cache entries.#1096
Conversation
|
Due to the conflict in README., I just noticed I haven't updated the granular save action, will fix that now. |
b5d67da to
ea4b956
Compare
|
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 Unfortunately, that might be a dealbreaker with that approach. |
I have tested it from a 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? |
ea4b956 to
351dc22
Compare
|
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) |
7755eb5 to
6e0386c
Compare
|
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? |
a25a486 to
4043ab8
Compare
|
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. |
4043ab8 to
0e80100
Compare
|
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. |
11a6324 to
1345410
Compare
|
1345410 to
bb91a1c
Compare
Signed-off-by: Gregorio Litenstein <g.litenstein@gmail.com>
Signed-off-by: Gregorio Litenstein <g.litenstein@gmail.com>
And rebuild. Signed-off-by: Gregorio Litenstein <g.litenstein@gmail.com>
Signed-off-by: Gregorio Litenstein <g.litenstein@gmail.com>
Signed-off-by: Gregorio Litenstein <g.litenstein@gmail.com>
Signed-off-by: Gregorio Litenstein <g.litenstein@gmail.com>
bb91a1c to
902f08f
Compare
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
deleteCacheByKeyfunction 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
runfunction 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
Checklist: