Add option to restore cache only

Description:
It would be nice to have the option to restore only and not save.

Justification:
In bigger repos, it's easy to hit the 10gb cache limit. Not caching in PRs can help with this.
Right now, I have to manually delete caches to help keep the caches on main alive.

Are you willing to submit a PR?

References
actions/toolkit#1308
Swatinem/rust-cache#95 (has a save-if option https://github.com/Swatinem/rust-cache#example-usage)

@ForsakenHarmony

Hello @ForsakenHarmony. Thank you for your report. We'll investigate the issue.

Found this searching for an open issue because I wanted to request the same feature. Some context on the specific use case I have.

In workflows triggered with the pull_request_target event, the recommendation in the docs is as follows:

Although the workflow runs in the context of the base of the pull request, you should make sure that you do not check out, build, or run untrusted code from the pull request with this event. Additionally, any caches share the same scope as the base branch. To help prevent cache poisoning, you should not save the cache if there is a possibility that the cache contents were altered.

When using the setup-node action, I'd like to turn off cache saving for runs triggered with this event.

It can also help when a GitHub matrix is used. On large matrices, we may end with concurrency on cache write, forcing the job to wait (more than 1m on my repo).

Post job cleanup.
/usr/bin/tar --posix -cf cache.tzst --exclude cache.tzst -P -C /home/runner/work/... --files-from manifest.txt --use-compress-program zstdmt
Failed to save: Unable to reserve cache with key <KEY>, another job may be creating this cache. More details: Cache already exists. Scope: refs/heads/main, Key: <KEY>, Version: <HASH>

Hi! Do you have any plan about this? In our case, we're handling the cache with a custom system, so we'd love to save some time in our workflows by disabling the save step.

@ForsakenHarmony

@ForsakenHarmony agree. In a big monorepo with 500+ open PRs and ~100 commits per day, the cache becomes unusable because there's too many circumstances where the main cache gets evicted because of hundreds of non-main caches. I can't decide if:

I need to control which bits of my pipeline are restore-only
I should automate purging all non-main caches

But it feels like a little of both are necessary

ci: add composite action to set up Yarn cache (#21475)

Hello Everyone, Thanks everyone for your patience and contributions. This issue reported here has been addressed in PR #1419, which is now merged. The documentation helps cache state restoration handling.
We are proceeding to close this issue as the related PR is merged, Please feel free to reach us in case of any further concerns to reopen this issue :)

@aparnajyothi-y that seems more like a workaround because you can no longer use the built in caching functionality?

Navigation Menu

Repository navigation

Add option to restore cache only #663

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Add option to restore cache only #663

Description

Activity

dmitry-shibanov commented on Jan 11, 2023

desrosj commented on Oct 25, 2023

hugo082 commented on Dec 28, 2023

marcferreiro commented on Jan 25, 2024

maschwenk commented on Feb 14, 2024

v-aparnajyothi-y commented on Oct 27, 2025

ForsakenHarmony commented on Nov 7, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions