Restore does not fall back to gzip if zstd is present
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 5.6k
- Forks
- 1.6k
- PR merge metrics
- No merged PRs in 30d
Description
When actions/cache/restore detects the presence of zstd on the path, it uses that to calculate the cache version it looks for. This leads to cache misses when the only available cache was created without zstd present.
In this case, the restore action should calculate the version again for gzip compression and try getting a cache with that version. When restore can handle both gzip and zstd compression, it should not limit the restorable cache version to only zstd.
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 tracing the restore action's cache-version calculation and its handling of zstd and gzip compression. The change is done when restore retries with the gzip version after finding zstd available, allowing caches created without zstd to be restored while retaining zstd support.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- github-actions, typescript
- Domain
- ci-cd
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100