Peculiar behaviour of GitHub Actions caches with respect to pull requests

[Niols]

We have been noticing peculiar behaviours of GitHub Actions caches in the past days. Turns out they are all normal and expected, there is just a notion of scoping involved. In particular:

• workflows triggered by pushes on main do not get access to caches created by workflows triggered by pull requests
• workflows triggered by pull requests get read access on caches from main and from the base branch of the pull requests, but they do not get access to caches of other pull requests.

The GitHub Actions documentation says in particular:

Access restrictions provide cache isolation and security by creating a logical boundary between different branches or tags. Workflow runs can restore caches created in either the current branch or the default branch (usually main). If a workflow run is triggered for a pull request, it can also restore caches created in the base branch, including base branches of forked repositories.

[...]

Workflow runs cannot restore caches created for child branches or sibling branches.

[...]

When a cache is created by a workflow run triggered on a pull request, the cache is created for the merge ref (refs/pull/.../merge). Because of this, the cache will have a limited scope and can only be restored by re-runs of the pull request. It cannot be restored by the base branch or other pull requests targeting that base branch.

[Niols]

In particular, it means you can have many caches all sharing the same key. A bit frustrating, but that's life. (Source for the picture.)