The ability to force-override a cache while using it.

[ItsLiyua]

I would like to see a feature, that allows you to override the content of a cache. For example when I cache my maven dependencies (.m2) It only saves the things required in the first job. Anything after that has to be redownloaded every time. When I run my first job (compile) it saves all the dependencies required to compile the code. When I generate javadoc during the third step (package) it downloads the javadoc plugin into the .m2 folder but does not save it because it found a cache, that was hit at the primary key. When I try to use the javadoc plugin during site generation it has to redownload it.

Same thing for build results. When I generate test reports in the second step, it does not save then because it already hit the cache, that was created during the first step (compile).

I have a workaround, where I enter the primary key of the job before as a restore-key and give it a new primary key but it is still annoying...

Thank you for reading my feature request.

[half2me]

Please add this, it would be super useful!

[bryceschober]

My use case is in caching contents that are in themselves a cache. In caching a .ccache directory, I want to save and restore the same contents across all related jobs repeatedly. And I want as few separate copies of it as possible using up my cache storage limit.

[half2me]

In my use case, I needed to pull a cache, update it to make it available to other sections of the pipeline. I've solved my issue by changing the name of the cache keys to be dynamic. For example, instead of using a hash key like: "my-cache", I'll use "my-cache-", where I'll dynamically calculate the hash based on the content. This way, if I try to cache the same content twice, it skips, but if I try to "update" the cache, it will have a different key, so it will make a new entry.

[0xFEEDC0DE64]

im still evaluating, if my build times go better with updating the cache at the end: https://github.com/actions/cache/compare/main...0xFEEDC0DE64:update-cache-on-cachehit

[akmjenkins]

Man, there's like a dozen issues open on the same topic here. I've created a gross but working hack that allows you to do just this because the maintainers of this repo won't just add the force feature.

If you have a cache that gets updated during the course of the job - in my case I am doing an eslint cache - then the trick is to create two caches. The first must never hit (use github.sha) and the second is your cache that might hit and actually restores your file(s):

      - name: Cache Lint Hack
        uses: actions/cache@v2
        with:
          path: '**/.eslintcache'
          # use github.sha so this cache will **never** get restored, and thus always saved
          key: ${{ runner.os }}-eslint-${{ github.sha }}        

        # this action actually restores a valid cache file 
      - name: Cache Lint
        uses: actions/cache@v2
        with:
          path: '**/.eslintcache'
          key: ${{ runner.os }}-eslint-${{ hashFiles('**/yarn.lock') }}        
          # the restore key must match the key in the **fake** cache action above
          restore-keys: |
            ${{ runner.os }}-eslint-

    # the rest of your work....

[MkMan]

I have a similar use case for this where I want to cache the cache generate by Nx so task outputs can be restored instead of running again.

@akmjenkins's suggestions looks feasible

[mkurz]

Duplicate of #342?

[github-actions[bot]]

This issue is stale because it has been open for 200 days with no activity. Leave a comment to avoid closing this issue in 5 days.

[0xFEEDC0DE64]

hello

[github-actions[bot]]

This issue is stale because it has been open for 200 days with no activity. Leave a comment to avoid closing this issue in 5 days.

[0xFEEDC0DE64]

because of shenanigans like this we migrated far away from microsoft and github and went with gitlab ci

[github-actions[bot]]

This issue is stale because it has been open for 200 days with no activity. Leave a comment to avoid closing this issue in 5 days.

[github-actions[bot]]

This issue was closed because it has been inactive for 5 days since being marked as stale.