Clarify the state of caching on PRs

[michaelpj]

The README says

Pull requests do not have access to secrets so read access to a public binary cache will work, but pushing will be disabled since there is no signing key.

Here Domen suggested that it might work so long as the person making the PR has write access to the repo.

However we tried this and it didn't seem to work. So I'm unsure what the actual behaviour is.

Why do we care? In this instance we have a PR which updates a bunch of nix dependencies, and needs to do a lot of building. It would be nice if this was cached between runs on the PR. Indeed, at the moment the PR does too much building for it all to pass in one go, so we were hoping to cache it in chunks. But we can't do that if pushing to cachix in PRs doesn't work. (Of course, we could build locally and push from there, but I don't think any of us have the cachix keys!)

[lafrenierejm]

When using the on.pull_request trigger, GitHub Actions restricts the workflow's access to the secrets of the source repository (the repository from which the PR originates) and prevents access to the target repository's secrets. This is by design to prevent exfiltration of a repository's GitHub secrets simply by raising a PR against the repository.

In your case where the maintainers of haskell-language-server wanted the pull request to have access to haskell/haskell-language-server's secrets, the process would be to create the feature branch directly on the target repo (haskell/haskell-language-server) rather than a maintainer's fork (smunix/haskell-language-server). Then when the PR is raised it would have access to haskell/haskell-language-server's secrets.