Caching fallback if there is no exact hit
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 5k
- Forks
- 1.7k
- Avg merge
- 3d 12h
- Merged PRs (30d)
- 2
Description
Hi there,
at the moment, caching only hits if the exact same lockfile exists, but most of the time, even it the lockfile slightly changes, it is still beneficial to restore cache instead of downloading everything from scratch (most likely only ~1 dependency changed).
I would propose that, by default, cache falls back to node-cache-${platform}-${packageManager} instead of only checking node-cache-${platform}-${packageManager}-${fileHash}.
If this is of interest, I'm happy to provide a PR. It seems to only need a test and a one line change in https://github.com/actions/setup-node/blob/main/src/cache-restore.ts#L44
See also https://github.com/actions/setup-node/issues/304#issuecomment-904553549
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start in src/cache-restore.ts around line 44 and inspect the current cache lookup behavior. Add or update a test covering fallback when the exact lockfile hash has no cache hit; done means the broader node-cache-${platform}-${packageManager} key is considered and the test passes.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- github-actions, node.js, typescript
- Domain
- ci-cd, tooling
- Issue type
- Feature
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Stale
- Clarity
- Clearly specified
- Newbie friendliness
- 55/100