Add option to restore cache only

[ForsakenHarmony]

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)

[dmitry-shibanov]

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

[desrosj]

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.

[hugo082]

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>

[marcferreiro]

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.

[maschwenk]

@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:

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

But it feels like a little of both are necessary