Cache: No chache hits when a branch only receives PRs

[gladhorn]

I have a protected master branch and it only gets updated with PRs. That means no action will run on the master branch. Each PR should come from a new unique branch that fits the feature/fix.
Currently I never see any cache hits, because of the scoping rules, if I understand correctly, that's expected, according to:
https://help.github.com/en/actions/configuring-and-managing-workflows/caching-dependencies-to-speed-up-workflows#restrictions-for-accessing-a-cache
What I would have expected though, is that when a branch gets merged into master, the caches from that branch build should also be "merged"/made available for master.

What other way is there to update a branch? I could start introducing an artificial push that regularly riggers a cache rebuild with an empty commit, but that's ugly and messes with the git history.

[joshmgross]

👋 Hey @gladhorn, for your use-case could you set up a workflow that runs off push events to your master branch? This would be used to populate the cache.

What other way is there to update a branch? I could start introducing an artificial push that regularly triggers a cache rebuild with an empty commit, but that's ugly and messes with the git history.

Merging a PR into master will trigger a push event on master

[gladhorn]

Yes, that's what we started doing. It seems somewhat wasteful, since that means running everything twice. We have some c++, so the action takes twenty minutes to complete. Then it will run the same again, just to populate the cache. Thanks to the cache of object files we get the computer time down to five minutes, but it might be worthwhile giving this Hint in the docs.
Thanks for getting back to this :)

[LinusU]

I'm already keying my cache on exactly what variables produces it, so I would love it if there was an option to have a global cache which any branch can read/write from...

[joshmgross]

Scopes on caches for pull requests also represent a strong security boundary to prevent malicious users from poisoning the cache for other pull requests. This is likely not a concern for private repositories, so a global cache could make sense for those use cases. @LinusU feel free to file a feature request issue with your use-case.