Resource not accessible by integration, GraphqlError: Resource not accessible by integration

[fizyk]

How would you describe the issue?
https://github.com/ClearcodeHQ/jira_timemachine/actions/runs/3327307904/jobs/5501967216
I'm getting this weird bug across all repositories I have. It happens after I merge the dependabot's pull requests (major version change so I have to do it manually) to main branch.

How can we reproduce the issue?

Not sure, merge something dependabot updates to major version to master?

What are the expected results?

One out of three:

• Not be triggered by main branch (unless theres' a setting I missed)
• Produce meaningful error message instead of traceback.
• Not fail 🤔

What are the actual results?

https://github.com/ClearcodeHQ/jira_timemachine/actions/runs/3327307904/jobs/5501967216

How much does it hurt?

Not sure yet, worst case scenario, if it fails on all prs, then that means I'll have to merge event the patch dependabot updates across many of my repositories, if it's main branch only, that means a lot of spam emails.
It fails also on regular patch updates so that means that the action does not work currently at all.
https://github.com/ClearcodeHQ/pytest-dynamodb/actions/runs/3326150718

[minizwergi]

Same issue for me and reproducible in multiple repositories. Each GH action is failing in this line
at branchProtectionRules (/home/runner/work/_actions/ridedott/merge-me-action/v2/webpack:/@ridedott/merge-me-action/src/common/listBranchProtectionRules.ts:54:1)

[zaneselvans]

Also experiencing this failure across all of our repos where we've used it to automate the merging of dependabot PRs, e.g.:

https://github.com/catalyst-cooperative/pudl/actions/runs/3327104257

[jexxa-projects]

The same problem happens on all repos where I use this action to automate merge process of dependabot PRs such as:
https://github.com/jexxa-projects/Jexxa/actions/runs/3326568476

[aaneitchik]

Hi everyone, sorry to hear you have these issues, and thank you for providing the examples. I'm not exactly a contributor to this action, but maybe I'll be able to help investigate this.

The first thing that I can see is that the action works as expected across our repositories, for example you can see a recent successful run also triggered by dependabot in this repository itself.

Secondly, I would say that the error message gives quite a lot of info: looking at the error message "GraphqlError: Resource not accessible by integration" and the code to which the stacktrace points to, I'm quite sure that what fails is this query to GitHub GraphQL API, so looks like the action fails to fetch branch protection rules, maybe some permissions missing?

The main difference that I see between the examples provided here and what this repo uses is the token that authenticates the action. This repository is using a custom one, while all of the failed examples use GITHUB_TOKEN which seems to be the default token for the actions. It's not clear to me from the docs what permissions this token has, and I would guess it's also possible that GitHub might have changed something recently, either the permissions given to GITHUB_TOKEN, or the permissions needed to query the branch protection rules.

It also seems that there is some mention of this in the action README, please see for example this section, an excerpt from there:

steps:
- name: Merge me!
uses: ridedott/merge-me-action@v2
with:
# Depending on branch protection rules, a manually populated
# GITHUB_TOKEN_WORKAROUND secret with permissions to push to
# a protected branch must be used. This secret can have an arbitrary
# name, as an example, this repository uses DOTTBOTT_TOKEN.
#
# When using a custom token, it is recommended to leave the following
# comment for other developers to be aware of the reasoning behind it:
#
# This must be used as GitHub Actions token does not support pushing
# to protected branches.
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

I would suggest you to try creating a custom token and try using that instead of the default GITHUB_TOKEN, unfortunately not sure what permissions exactly it must have, I would guess at least things like reading branches/branch protection rules and writing to protected branches as well, as the PRs will usually be merged to main branch that should be protected.

Hope this helps.

[fizyk]

@aaneitchik you mean the fine-grained tokens that are in beta? Classic/regular tokens have only read-only access to public repositories.
And... it still worked fine last week 😕

[aaneitchik]

you mean the fine-grained tokens that are in beta?

no, definitely not the fine-grained tokens, as they're not supported by the GraphQL API that is used in this action.

Classic/regular tokens have only read-only access to public repositories.

Could you please clarify what you mean by that? I definitely could be missing something, but looking at the docs I think you should be able to also grant write permissions to classic tokens as well.

And... it still worked fine last week

I understand that, but it's also continues working for some repositories, that's why I mentioned that it could be that something changed in the GitHub API. Maybe you could also try checking if anything from here applies to your case.

[quotidian-ennui]

@aaneitchik is right, it's a permissions thing, but it's now apparent that as of the start of the week (2022-10-24) the standard action token cannot access the protected-branches

You can replicate what merge-me is doing (thanks to aaneitchik) by having this step; it's a 200 OK, but the error message is the effectively the same.

c.f https://github.com/quotidian-ennui/aws-kms-csr/actions/runs/3338749933/jobs/5526810170

      - name: can-query-protected-branches
        id: can-query-protected-branches
        continue-on-error: true
        run: |
          BRANCH_QUERY='{ repository(name: "aws-kms-csr", owner: "quotidian-ennui") { branchProtectionRules(first: 10) { edges { node { id } } } } }'
          GRAPH_QUERY=$(jq -n --arg q "$(echo $BRANCH_QUERY | tr -d '\n')" '{ query: $q}')
          curl -X POST \
          -si \
          -H "Accept: application/vnd.github.package-deletes-preview+json" \
          -H "Content-Type: application/json" \
          -H "Authorization: bearer ${{ secrets.GITHUB_TOKEN }}" \
          --data "$GRAPH_QUERY" \
          --url https://api.github.com/graphql

If I add my "personal access token" as a secret so merge-me-action is now configured with GITHUB_TOKEN: ${{ secrets.MERGE_ME_SECRET }}; then things are auto merged.

Note that I did add permissions: write-all into my github-action at one point, and that still didn't work so the appropriate permission doesn't seem possible with the normal action secret.

I don't consider using a PAT a viable solution (it's a temporary work-around) since from an audit trail perspective; I am marked as having approved the PR and this might matter...

• build(deps): bump aws-java-sdk-kms from 1.12.327 to 1.12.329 quotidian-ennui/aws-kms-csr#229 (approved by me, because it's my personal access token)
• build(deps): bump aws-java-sdk-kms from 1.12.325 to 1.12.326 quotidian-ennui/aws-kms-csr#226 (approved by git-actions).

[fizyk]

Quote from https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token

Note: Workflow runs triggered by Dependabot pull requests run as if they are from a forked repository, and therefore use a read-only GITHUB_TOKEN. These workflow runs cannot access any secrets. See ["Keeping your GitHub Actions and workflows secure: Preventing pwn requests"](https://securitylab.github.com/research/github-actions-preventing-pwn-requests) for strategies to keep these workflows secure.

So.... maybe that's the case here, why the github_token stopped working for dependabot PRs 🤔 not sure though when it was introduced.

And yes, PAT works when set up.

[antoineco]

@fizyk It also fails for non-Dependabot workflows.

Note that PAT isn't the only authentication method that fixes this issue. It is also possible to set up a GitHub App with finer-grained permissions, and impersonate it inside workflows. This is in fact much more secure, and the recommended approach.

The permissions required to use this Action are:

• Administration (Read-only)
• Pull request (Read-only)
• Contents (Read and write)
• Metadata (Read-only)

[fizyk]

@antoineco could you write a bit more about the GitHub app approach? Any specific setting to set on the Github Actions?

[antoineco]

Sure thing:

1. Start by creating an App if you haven't already. For a "bot" type of App you can pretty much leave all default settings untouched (no OAuth, no device flow, no setup URL, no webhooks).
2. After creating the App, make sure it has sufficient permissions to do whatever you want it to do (see my previous comment for the minimum set of permissions required by merge-me). This can be changed anytime, but might require accepting permission changes once the App is already in use.
3. Generate a private key for your App. It will be downloaded to your workstation. After that you won't be able to download it again so keep it somewhere secure. (This step can also be performed later.)
4. Install the App in the repos that need to use it. This can be done either in the App's settings or from the repos' settings pages.
5. In the repo(s) where you use merge-me, create two repository secrets named e.g. APP_ID and APP_KEY containing the App's ID (visible in the App's settings) and private key (which GitHub downloaded for you) respectively. These names are completely arbitrary, only their contents matter.
6. Inside your GitHub Action workflow(s), request a short-lived App token using either an API call to GitHub or an Action such as tibdex/github-app-token (demonstrated here).
7. Use this token in place of the regular GITHUB_TOKEN (also demonstrated here).

[tucksaun]

Given that probably several people here use this action to auto merge dependabot PRs on free private repositories where branch protections rules are not enforced by GitHub anyway, would it makes sense to add an option to not check those when the action is running?