actions/cache@v3 does not appear to properly compare cache
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 5.9k
- Forks
- 1.8k
- PR merge metrics
- No merged PRs in 30d
Description
Describe the bug
I've updated a local package-lock.json file in a subdirectory in our project. We are using the actions/cache@v3 github action to cache NPM data and if data is different re-install npm packages. But the cache key comes back as successfully restored despite the debug log showing the keys generated were different from the cached keys. It appears based on logs that it doesn't even compare the key at all?
This is our action in our yaml file:
- name: Cache NPM
uses: actions/cache@v3
with:
path: ${{env.dir}}
# We include the version in the key to keep the cache size under control, effectively clearing it for each version bump
key: ${{ runner.os }}-${{ hashFiles('src/Version.txt') }}--node-main-${{ hashFiles('src/**/package-lock.json') }}
restore-keys: |
${{ runner.os }}-${{ hashFiles('src/Version.txt') }}-node-main-
To Reproduce
Steps to reproduce the behavior:
- Makes changes to local package-json files
- Run the github workflow
- It claims the cache was successfully restored despite files being different.
Expected behavior
Expected that after changing the package-lock.json file the cache would have a miss and go through the steps such as npm install on the github workstation and build a new cache and key.
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):
- OS: Windows 11 Pro 22H2
- Browser: Firefox
- Version: 22621.1848]
Additional context
I've included a copy of the debug log during the run:
Contributor guide
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 by reading the attached debug log and the workflow's key and restore-keys configuration. Compare the generated keys with the cache restore behavior after changing package-lock.json; done means determining whether this is an actions/cache@v3 failure or expected restore-key behavior, with a reproducible case if it is a bug.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- github-actions
- Domain
- ci-cd
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100