[BUG] Github Actions: Resource Not Available to Integration

[fbartho]

Describe the bug
In DangerJS lately, I've been getting 403 errors when it's trying to fetch the previous comments, so it's constantly duplicating the danger message.

Actions Log Output

$ /github/workspace/node_modules/.bin/danger ci --id main --dangerfile ./scripts/danger/main.ts
:+1: Jest tests passed

Main Dangerfile Loaded

{
  fails: { numEntries: 0, sumNumChars: 0 },
  warnings: { numEntries: 0, sumNumChars: 0 },
  messages: { numEntries: 1, sumNumChars: 123 },
  markdowns: { numEntries: 0, sumNumChars: 0 }
}

{ spacePerMessage: 64987, shortenedSpacePerMessage: 64984 }
Found only messages, passing those to review.
Request failed [403]: https://api.github.com/user
Response: {
  "message": "Resource not accessible by integration",
  "documentation_url": "https://developer.github.com/v3/users/#get-the-authenticated-user"
}
Request failed [403]: https://api.github.com/user
Response: {
  "message": "Resource not accessible by integration",
  "documentation_url": "https://developer.github.com/v3/users/#get-the-authenticated-user"
}
Feedback: https://github.com/taskrabbit/tr_client/pull/1345#issuecomment-611692062

To Reproduce

Steps to reproduce the behavior:

1. Configure DangerJS to run in Github Actions using the default token
2. I assume let Github change some semantics
3. Notice comments start duplicating

Speculation: this might also be affected by a long-running PR that had many comments, but my testing suggests that this isn't actually in play here :-/

Expected behavior

Since I've configured danger to update the same comment in place, it should be able to do just that instead of duplicating comments.

Your Environment

software	version
danger.js	9.2.10, 9.4.x, 10.1.0
node	12.16.1
npm	6.13.4
Operating System	Github Actions (linux)

Additional context
Add any other context about the problem here.

[fbartho]

I'm thinking that this is Github that changed the permissions available to the secrets.GITHUB_TOKEN so that it can't read past comments anymore.

[orta]

¯\_(ツ)_/¯

[fbartho]

If other people see this, it might be worth documenting that the update/replace mode of Danger cannot work with github actions :(

What do you think, @orta?

[orta]

Personally, I'd wait to see if it's more than just you ATM

[NotMoni]

I agree with @orta.

[fbartho]

That’s cool, I’ll leave this ticket open for a while then, so see if others run into this.

We were able to shift our stuff to a dedicated bot account, so workaround applied for me.

[G-Rath]

We've just had this in this PR.

I've not actually done that much work with Danger (but it looks cool!), so let me know what other details you'd like :)

Actually sorry same error message different cause:

Failing the build, there is 1 fail.
Request failed [403]: https://api.github.com/repos/jest-community/eslint-plugin-jest/issues/581/comments
Response: {
  "message": "Resource not accessible by integration",
  "documentation_url": "https://developer.github.com/v3/issues/comments/#create-a-comment"
}
Feedback: undefined

Let me know if you'd like a new issue opened :)

[orta]

I wonder if we should update the docs to not recommend using the GH auth token - #1040 seems be having similar issues

[fbartho]

It's really the combination of "updating the same comment in place" + "the GH actions token cannot read comments, or a user profile" that cause problems.

Obviously, in my opinion that's the most useful configuration of DangerJS.

[fbartho]

Maybe there's a way to find the comments that the GH Action Token can access? Must we fetch the user profile to do this? -- if the GH Token can post comments, I'd be surprised that it can't enumerate comments.

[orta]

Danger should only be editing posts which it makes (it looks for exact strings matches in the issues and checks the user account matches ) - it's possible that the key doesn't have access to edit its own posts

[fbartho]

@orta it’s failing when fetching its own profile.

I’m not deep in the code this second, but I think danger fetches the Profile to figure out what user_id is associated with a given GITHUB_TOKEN

Maybe there’s a different Github API that this can use to verify a token is genuine, and then find comments from itself?

[fbartho]

@orta I think this is the line it’s tripping up at:

danger-js/source/platforms/github/GitHubAPI.ts

Line 138 in 5ad5fd9

const info = await this.getUserInfo()

Is there some other way to determine the user_id for a given token?

[orta]

That's a GH bug that they've had for a long time, but I'd have expected it to hit this branch?

    const useGitHubActionsID = process.env["GITHUB_WORKFLOW"]
    if (useGitHubActionsID) {
      return 41898282
    }

[fbartho]

You’re right, that might not have been the right code path. I’ll keep looking!

[denieler]

facing the same issue in our integration :(

[orta]

Do not do this ^ for pull requests on public projects because it is a security hole (it'd be trivial for someone to make a PR which self merges for example)

[gabsmprocha]

Hi! any fix for this issue?

[gabsmprocha]

Hey guys, after searching a little, it seems that the GITHUB_TOKEN by default doesn't have some role needed to integration, if you create a new PAT and give the repo scope, add it to danger job on github actions, and the 403 error is no longer displayed

[fbartho]

Hey folks! I resolved this two different ways in different repos.

Originally, it worked out with a a custom Personal Access Token -- as described by @gabsmprocha, but in a new repo, we resolved it by giving the appropriate permissions in the workflow .yaml file:

permissions:
  actions: write
  checks: write
  contents: write
  # deployments: read
  issues: write
  pull-requests: write
  statuses: write

Note: your exact needed permissions depend on what exactly your Dangerfile tries to do!

Announcement for the Permissions Feature + Docs

Note: you'll still see console log messages about 403 errors, as DangerJS doesn't know what permissions a token has until it hits different APIs, so as an example, our repo sees two 403 errors in the logs on every danger run, but it succeeds at posting/updating comments, as well as marking commits as failed/or green.

I'm going to close this ticket, as there are 2 workarounds, and my original issue was a long while ago. If these workarounds don't work for you, please file a new ticket with an updated description of exactly what you're seeing + ideally a snippet of the Permissions you've attached to the custom token, or the Permissions you've applied to your workflow file!

[fbartho]

Screenshot of a Successfully posted/updated DangerJS run. Despite the successful operation, it still logs errors of "Resource not available to integration"

[peterrus]

This issue started manifesting itself (for me) on Dependabot PR's because they get a GITHUB_TOKEN with lesser permissions by default. This might also be the case for forks, but I don't use them.

The workaround does help but I am still worried about any potential side effects from Danger not being able to fetch it's own profile information.

[airtonix]

DangerJS should fail if it can't use the API.

  actions: write
  checks: write
  contents: write
  # deployments: read
  issues: write
  pull-requests: write
  statuses: write

It would be a good idea for the error messages comming out of dangerjs to also mention that "posibly calls to this method may fail if your token does not include permission X"

then for each method, identify what api calls it's making and correlate it to the permissions we can set for our actions when using the secrest.GITHUB_TOKEN.

what I'm not suggestion is that you just say: "this method may fail if your PAT does not have the repo scope".

[airtonix]

you can also use this page to help you correlate further details to give users to help them craft tokens with specific scopes:

https://docs.github.com/en/rest/overview/permissions-required-for-github-apps#permission-on-profile