I'm having this issue when trying to use @actions/cache for reducing update time of the built-in MSYS2 installation on windows-latest virtual environments. The virtual environments are outdated quite fast, and currently 5503.95 MiB need to be downloaded and installed on each job. It takes 8-10 min.

As commented in msys2/setup-msys2#23, I'm trying to save /var/cache/pacman/pkg/. However, actions/checkout@v2 allows to do it once only. Later executions skip it: https://github.com/eine/setup-msys2/runs/737062486?check_suite_focus=true#step:12:2

Post job cleanup.
Cache hit occurred on the primary key msys, not saving cache.

Then, I tried using the npm package: https://www.npmjs.com/package/@actions/cache. Unfortunately, it fails: https://github.com/eine/setup-msys2/runs/738298072?check_suite_focus=true#step:4:116

##[error]reserveCache failed: Cache already exists. Scope: refs/heads/tool-cache, Key: msys2-nokey, Version: 000d31344dacf74d63d9e122f85409f68c5697c2aa32c5626452e8301c5d0c66

As an alternative to updating an existing key, it would be feasible to remove it explicitly (ref #340).

This would also be super handy for persisting the test cache when using GitHub Actions in go projects. For example, I could download the latest test cache, run my tests then update the existing cache with the results of the tests in the current run.

This way, I can have a global test cache across all my workflow runs.

This also applies to things like webpack loader cache, small, have their own key management, needs to be updated each time

This would be super valuable for monorepo's where each subproject has its own dependencies it wants to cache and build so that upstream projects have faster build times.

I ran into the expectation that this was already the default behavior - so I wrote #392 under that assumption

Is there any workaround for forcing the update of the cache even on a hit? I can't think of any way...
In my case it would reduce the compilation time from 20 minutes to 3 minutes if I could use ccache for QT/C++.

Maybe save as ccache-${{ github.run_id }} and restore with restore key ccache-.
github.run_id is unique id for the workflow run, so every time a new cache is saved.
When restoring you will never have an exact match but then the ccache- restore key will restore the latest one that started with that string and in the end create a new one with the current state.

@Vampire that's brilliant, thanks mate! You are right, forgot about the pattern matching that the cache finding does. Perhaps this is then a non-issue and your solution is the intended way of doing things?

Nah, that's merely a work-around.
It will fill up your 5 GiB of cache and then evict things that might not have been evicted if the cache would have been updatable.

@HebaruSan It won't save anything at all.

https://github.com/actions/toolkit/blob/73d5917a6b5ea646ac3173cfceb727ee914ff6ed/packages/cache/src/cache.ts#L166-L175

Duplicate of #171

For anyone performing the gh workaround and doesn't want to checkout the repository in the job running it, you just need to provide a GitHub token and the repository name:

cache-sha:
  # Caches the SHA of the last successful build
  runs-on: ubuntu-latest
  steps:
    - name: Clear cache
      continue-on-error: true # Don't fail if the cache doesn't exist
      env:
        GH_TOKEN: ${{ github.token }} # required by gh
      run: |
        gh extension install actions/gh-actions-cache
        gh actions-cache delete ${{ env.CACHE_NAME }} --confirm -R ${{ github.repository }}

FYI when using the cache deletion trick and getting Error: Resource not accessible by integration you have to enable Read and write permissions under repo settings under Actions -> General -> Workflow permissions

Hey @bethanyj28, what's the reason such a feature has not been shipped yet? It is built-in in Gitlab, etc. It is the 2nd top most requested. And it seems it is doable (they are workarounds but cumbersome)

mutable cache that exists just during single run of workflow would be awesome option.
it should not be default behavior but possibility will be convenient, it would help to checkout sources ones and keep them from job to job (of single workflow) to let each job mutate/update file system as required and help following job to reuse it.

our workaround was: to create one more cache file.

from job to job (of single workflow) to let each job mutate/update file system as required and help following job to reuse it.

@romani you can use artifacts for that too, just overwrite the existing one and cache it in the last job to make it permanent across workflows (if desired).

https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/storing-and-sharing-data-from-a-workflow#comparing-artifacts-and-dependency-caching

Use artifacts when you want to save files produced by a job to view after a workflow run has ended, such as built binaries or build logs.

Nuance is that in our case we do not want to share some files after workflow ended.
We can hack everything to do what we need, but we tried to not polluting outside of workflow.