Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] Request failed [403]: https://api.github.com/user #1368

Open
jcook-uptycs opened this issue Mar 14, 2023 · 3 comments
Open

[BUG] Request failed [403]: https://api.github.com/user #1368

jcook-uptycs opened this issue Mar 14, 2023 · 3 comments

Comments

@jcook-uptycs
Copy link

Describe the bug

Danger sends errors to the output for failed https://api.github.com/user connections.

While this does not cause danger to error, it does cause anyone who looks at the output to think danger failed because of a permissions issue, and ignores everything else.

We use the auto created token in GitHub workflows for Danger as it provides the access we need and doesn't have too much access.

To Reproduce
Steps to reproduce the behavior:

  1. Use the CI created GITHUB_TOKEN with danger.

Expected behavior

How can we make this more clear that this is NOT causing any issues. Not sure if it shouldn't show, or someway to display differently that doesn't make the user feel danger failed due to the 403 error.

Screenshots
If applicable, add screenshots to help explain your problem.

Request failed [403]: https://api.github.com/user
Response: {
  "message": "Resource not accessible by integration",
  "documentation_url": "https://docs.github.com/rest/reference/users#get-the-authenticated-user"
}
Request failed [403]: https://api.github.com/user
Response: {
  "message": "Resource not accessible by integration",
  "documentation_url": "https://docs.github.com/rest/reference/users#get-the-authenticated-user"
}

Your Environment

software version
danger.js 11.2.4
node v19.4.0
npm 9.2.0
Operating System Ubuntu

Additional context
Add any other context about the problem here.

@orta
Copy link
Member

orta commented Mar 14, 2023

Pretty sure someone tried to fix this recently and had to be reverted, open to carefully thought out PRs for it

@jcook-uptycs
Copy link
Author

Is there a way to just suppress the error message instead of changing where it's run at?

@orta
Copy link
Member

orta commented Mar 21, 2023

Probably, I think you'd need to look into how the API is called, as I assume it uses octokit for those API calls which would I think is writing the logs there. Could probably special case that specific API call somehow?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants