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

[jcornaz]

In pull requests we often get:

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

And the build runs without cache.

Please note that I'm talking about pull request build triggered when pushing a commit (or opening the PR). So this issue is not explained by #129.

[joshmgross]

Can you provide an example of when this occurs?
Do you see it on the first PR run, or when re-running a PR?

[jcornaz]

Can you provide an example of when this occurs?

Not really sorry. I am not allowed to share that sources. I'll try to create a simple reproducer if I can.

Do you see it on the first PR run, or when re-running a PR?

If I look at the latest occurrence of the problem, it was when pushing a new commit to a PR already built.

[jcornaz]

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.
  
  

[bxq2011hust]

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.

[joshmgross]

@bxq2011hust Thanks! I believe there's a bug that re-running a PR will use a different ref (https://github.community/t5/GitHub-Actions/GITHUB-REF-is-inconsistent/td-p/48129). This fails our validation as we currently only allow caching on PRs that use refs/pulls/* type refs.

@jcornaz can you confirm if all of these cache failures were from re-running a failed PR?

[Raul6469]

Hi! I do have the same error message, however it also happens sometimes when I run a workflow for the first time, not necessarily after a re-run. Unfortunately, it looks like this issue happens quite randomly...

[joshmgross]

@Raul6469 could you provide a workflow file or an example run where this occurs?

[Raul6469]

I cannot give a link to a run since it's from a private repo, but here is one of the four jobs of the workflow. When the cache issue happens, it happens for all jobs of the workflow. Workflow is triggered on pull_request events.

And after some thought, I'm not 100% sure that the issue happened without a rerun 🤔 I'll let you know if it happens again

  lint:
    name: 'Lint'

    runs-on: ubuntu-latest

    timeout-minutes: 5

    steps:
    - uses: actions/checkout@v1

    - name: Use Node.js 8
      uses: actions/setup-node@v1
      with:
        node-version: 8

    - name: Cache npm
      id: node_modules
      uses: actions/cache@v1
      with:
        path: ~/.npm
        key: node-${{ hashFiles('**/package-lock.json') }}
        restore-keys: |
          node-

    - name: Install dependencies
      run: npm i

    - name: Run linter
      run: npm run lint -- --quiet

[jcornaz]

@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.

[joshmgross]

@jcornaz or @Raul6469, if you can give me the Run ID then I can look up the relevant info on my end.

You should see this value in the URL of a run. For example, the run https://github.com/actions/cache/actions/runs/45076896 has a Run ID of 45076896

[jcornaz]

@joshmgross, Here is the run id of the PR I mentioned encountering the issue on the first build: 489954217.

[joshmgross]

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

[jcornaz]

@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.

[sjackman]

I've also experienced this error.

[warning]No scopes with read permission were found on the request.
…
Post job cleanup.
[warning]No scopes with write permission were found on the request.

@joshmgross See for example run ID 540544450

[ThiefMaster]

Happened in my repo as well for a single PR while working fine for everything else. After a while it started working again for that PR as well.

Link to a failed build (cache actions in the setup step): https://github.com/indico/indico/runs/546586138?check_suite_focus=true

[manuyavuz-pointr]

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!

[manuyavuz-pointr]

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!

[joshmgross]

👋 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".

[Ryssa]

I've been experiencing this issue as well. Sometimes re-running the GitHub actions flow or pushing a new commit makes it work again, but sometimes it doesn't.

In case it can be helpful, that's our GitHub configuration:

```name: integration

on:
pull_request:
branches:
- development
- master

env:
CI: true

jobs:
install-dependencies:
runs-on: ubuntu-latest
steps:
- name: Checkout Repository
uses: actions/checkout@v1

  - uses: actions/setup-node@v1
    with:
      node-version: '12.x'

  - name: Restore Dependencies
    id: node-modules-cache
    uses: actions/cache@v1
    with:
      path: node_modules
      key: ${{ runner.OS }}-node-modules-${{ hashFiles('**/package-lock.json') }}

  - name: Install Dependencies
    if: steps.node-modules-cache.outputs.cache-hit != 'true'
    run: npm ci

  - name: Cache Dependencies
    if: steps.node-modules-cache.outputs.cache-hit != 'true'
    uses: actions/cache@v1
    with:
      path: node_modules
      key: ${{ runner.OS }}-node-modules-${{ hashFiles('**/package-lock.json') }}```

[joshmgross]

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