action:clean cache after branch closes

[Desiki-high]

Caches have branch scope restrictions in place, which means some caches have limited usage options. We should clean cache after branch closes.
See https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows#force-deleting-cache-entries.

[anolis-bot]

@Desiki-high , a new test job has been submitted. Please wait in patience. The test job url: https://tone.openanolis.cn/ws/nrh4nnio/test_result/73613

[codecov]

Codecov Report

Merging #1281 (b23f0d9) into master (5f76e8b) will decrease coverage by 0.02%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #1281      +/-   ##
==========================================
- Coverage   45.08%   45.07%   -0.02%     
==========================================
  Files         126      126              
  Lines       37403    37403              
  Branches    37403    37403              
==========================================
- Hits        16863    16858       -5     
- Misses      19649    19656       +7     
+ Partials      891      889       -2     

see 3 files with indirect coverage changes

[bergwolf]

Once a repository has reached its maximum cache storage, the cache eviction policy will create space by deleting the oldest caches in the repository

Are we seeing any issues with this behavior? IOW, the description is not clear why we need to clean up caches instead of letting GH handle it.

[Desiki-high]

Once a repository has reached its maximum cache storage, the cache eviction policy will create space by deleting the oldest caches in the repository

Are we seeing any issues with this behavior? IOW, the description is not clear why we need to clean up caches instead of letting GH handle it.

In our repo, the cache approach total cache storage limit always happened. The reson is pr changed the depences, such as go.sum or Cargo. toml, created new cache. After pr merged, GH will created new cache, the cache created by pr branch is still exited.
If we let GH handle it, GH will choose cache by time. Absolutely, the cache we deleted will never used again. So we can use this workflow to prevent cache thrashing. I think it just a optional solution, I'm not sure whther it can resolve the problem that cache approach total cache storage limit.

[Desiki-high]

Once a repository has reached its maximum cache storage, the cache eviction policy will create space by deleting the oldest caches in the repository

Are we seeing any issues with this behavior? IOW, the description is not clear why we need to clean up caches instead of letting GH handle it.

In our repo, the cache approach total cache storage limit always happened. The reson is pr changed the depences, such as go.sum or Cargo. toml, created new cache. After pr merged, GH will created new cache, the cache created by pr branch is still exited. If we let GH handle it, GH will choose cache by time. Absolutely, the cache we deleted will never used again. So we can use this workflow to prevent cache thrashing. I think it just a optional solution, I'm not sure whther it can resolve the problem that cache approach total cache storage limit.

The specific scenario is that the cache I saved in benchmark is deleted by GH once. Since benchmark doesn't run every day, the last cache might be replaced by the one generated by pr. I'm just trying to reduce the possibility of this happening.

[anolis-bot]

@Desiki-high , The CI test is completed, please check result:

Test Case		Test Result
build rust golang image		✅ SUCCESS
compile nydusd		✅ SUCCESS
compile ctr remote		✅ SUCCESS
compile nydus snapshotter		✅ SUCCESS
run container with rafs		✅ SUCCESS
run container with zran		✅ SUCCESS
run container with rafs and compile linux		✅ SUCCESS

Congratulations, your test job passed!