Cache always empty in new branches

[CharlieTap]

I'm guessing this is somewhat intended from reading the docs on cache keys, my question is more around why it works this way. If I populate the cache in the master branch, I'm not able to access the cache on first run of a new PR branch. Given most of the code base hasn't changed, the cache is just as relevant here.

Is there any plans to change this behaviour?

[bigdaz]

By default caches are only written from the default branch. You can read about the reasoning here: https://github.com/gradle/gradle-build-action#using-the-caches-read-only

If I populate the cache in the master branch, I'm not able to access the cache on first run of a new PR branch.

This isn't the intended behaviour, and is certainly not what I see when using the action. Do you have job executions that you can share that display this behaviour? If not, are you able to share the Job summary (with cache entry details) for the master and PR jobs? You should see something like this: https://github.com/gradle/gradle-build-action/actions/runs/3152142285#summary-8620301833

[CharlieTap]

So I've made a repro repository here. You can see the most recent two actions have completed, the earlier one writes to cache but from a different branch. The latest action is associated with a new branch and you can see it its unable to read from the cache.

This is a bit of an odd scenario I can appreciate, because these workflows are actually launched on a pr branch, and that same workflow will clone both the master branch and the branch of the pr to benchmark and compare.

[bigdaz]

Thanks for creating a reproducer. I've been on vacation and am just getting back to this now. I think I understand what you're seeing, but please help me clarify.

Results

Benchmark 3

Looking at the Benchmark #3 run, you can see that cache entries were restored in both the benchmark-master and benchmark-pr Jobs:

'benchmark-master':

'benchmark-pr':

Benchmark 4

However in the Benchmark #4 run, you can see that no cache entries were restored in either the benchmark-master or benchmark-pr Jobs:

'benchmark-master':

'benchmark-pr':

Analysis

The question is, what is different between these 2 workflow runs (benchmark 3 and benchmark 4).

The first important consideration is that GitHub Actions cache entries are scoped based on the branch that the workflow is executed against (and is unrelated to any branch provided to actions/checkout). This is core behaviour of the GitHub Actions infrastructure, and I don't think can be changed/overridden by the gradle-build-action.

I see that you're invoking the Job using the workflow_dispatch trigger, which allows you to choose the workflow branch for execution. So if you choose the specific (leaf) branch when invoking, any cache entries will be private to workflows executed against that same branch, and won't be visible to workflows scoped to other branches. Again, this is based on the branch where the workflow is sourced from, not the branch provided to actions/checkout.

What branch name are you choosing when running the workflow manually, and is this ever the main branch of the repository?

[CharlieTap]

Ah thats interesting I didn't know that, from a quick skim of the Github cache plugin its seems you should be able to share the cache between descendant branches. I.e. If I populate the cache in main, my PR branches should inherit this cache. I'll leave this a note for others that come across the same problem.

I'll close this now as that's a clear limitation, thank you for your help :)

[bigdaz]

Ah thats interesting I didn't know that, from a quick skim of the Github cache plugin its seems you should be able to share the cache between descendant branches. I.e. If I populate the cache in main, my PR branches should inherit this cache. I'll leave this a note for others that come across the same problem.

Yep this is exactly why the cache is read-only by default for branches other than main. Writing cache entries from these branches is likely to result in private entries that are never used (but could lead to eviction of other, shared entries).