cache: Cache fails for Pull Request re-runs with "No scopes with read permission were found on the request."

👋 Hey all, thank you for your patience. Pull Request re-runs should now have the correct GitHub Ref and work with this action.

👋 Hey all, we’re working on this issue but it will require fixes internally to fix the GitHub ref for pull request re-runs.

For some background, every cache has a “scope” (see Docs: Matching a Cache Key which is determined by the GitHub ref of the current event that triggered the workflow run (as well as the event type itself).

The scope is encoded in the JWT token used by the action to authenticate to the internal cache service. The scope is used to determine which caches we can read and write to and is intended to prevent any potential security issues. For example, you wouldn’t want a pull request from a fork to be able to write to the cache on the default branch.

The logic that determines what scopes to give the token also validates that the ref of the pull request is valid (refs/pulls/*). When a pull request ref does not match that format, we don’t give any scopes to the token. This is why you see the error “No scopes with read permission were found on the request”.

@joshmgross I found a pull request that encountered this issue on the first build of the pull request.

So no, these cache failures don’t happen only when re-running a failed PR.

Hmm, I read through the code a bit, and it does not seem easy to fix as actions/cache uses actions/core to get the state which includes a scope value which I assume corresponds to github ref which is different between first run of a commit, and a re-run through github UI.

So either state generation under actions/core should change, or actions/cache should override state and handle this scope change. Honestly, I understand that first run via commit push should have a different state than manual trigger via UI, but it should not be resulted from the change in GITHUB_REF imo.

@joshmgross do you have any plans on how to fix this?

Thanks!

Hi,

Obviously this is still an issue as we just experienced the same problem.

Is there anything I can help to fix the problem, or build ID to reproduce steps?

Also, is there any known workaround, other than amending the latest commit and force pushing it to PR branch again?

Btw, we are using actions/cache@master to be able to use caching multiple paths.

Thanks!

@jcornaz Can you confirm that 489954217 is the correct number? It’s a little larger than I’d expect

Yes it is correct. if I go to https://github.com/REPO_OWNER/REPO/runs/489954217 i get the log of the concerned run.

I have the same problem. Sometimes a pr runs without cache and GitHub Action output.

[warning]No scopes with read permission were found on the request.

Today I meet the problem after I cancel and rerun. Here is the link https://github.com/FISCO-BCOS/FISCO-BCOS/pull/1402/checks?check_run_id=493039648

 Run actions/cache@v1 0s
[warning]No scopes with read permission were found on the request.
Run actions/cache@v1
[warning]No scopes with read permission were found on the request.
  Run actions/cache@v1 1s
[warning]No scopes with read permission were found on the request.
Run actions/cache@v1
[warning]No scopes with read permission were found on the request.

In the hope it helps, here is more information:

• We configured action/checkout to build the HEAD of the PR branch (not the merge commit).

      - uses: actions/checkout@v2
        with:
          ref: ${{ github.event.pull_request.head.sha }}

• Here is how we configure the workflow to run on build requests:

on:
  pull_request:
    branches:
      - master
    paths-ignore:
      - '**/*.md'

• The workflow is composed of multiple jobs, all using the same cache key.
  • One initial job. runs alone
  • The next jobs run all in parallel and use matrix strategies. That causes ~ 20 concurrent fetches of the same cache.