Invalid badges when using with fine grained PAT in GitHub

[SayakMukhopadhyay]

Are you experiencing an issue with...

My own instance of shields

🐞 Description

I was trying too use fine grained PATs for my instance of Shields, especially after being mentioned in #8790 (comment).

Most badges work fine, including contributers, stars but the issues and pull requests badges are showing as INVALID is both private and public repos.

I have tried multiple combinations of permissions and none have worked so far. Right now I have given access to:

Read access to actions, administration, code, commit statuses, deployments, discussions, issues, metadata, pull requests, repository hooks, and security events

As you might notice, I have given lots of unneeded permissions too. In case of the old classic PAT's given the repo permission was enough.

🔗 Link to the badge

No response

💡 Possible Solution

I have no idea what the problem is, as I don't see any logs. I am running the server on Kubernetes and using the default entrypoint in the container.

[chris48s]

I'm learning at the same time as you here - this is all new to me too.

Some of our GitHub badges use the REST API. Some of them use the GraphQL API. The pull request and issue badges both query the GraphQL API. Just looking at the docs at https://docs.github.com/en/graphql/guides/forming-calls-with-graphql they say

You need to create a personal access token (classic), GitHub App, or OAuth App to authenticate to the GraphQL API. The GraphQL API does not support authentication with fine-grained personal access tokens.

TIL 🎓

so I guess that means there is a subset of our badges that won't work with a fine-grained PAT :(

FWIW, I reckon the subset that won't work with a fine-grained PAT are:

• issues/PRs
• forks
• tags
• deployments
• sponsors
• file count
• commit activity
• discussions
• hacktoberfest
• gist stars

and probably all the others will (given the right permissions).

[SayakMukhopadhyay]

Ahh! That makes sense. And thanks for figuring out which ones won't work. Its possible that GitHub will implement fine grained PATs with GraphQL endpoints in the future, at least I hope so.

I feel it would be better to keep this issue open or add documentation around this. Which one do you prefer?

[calebcartwright]

I feel it would be better to keep this issue open or add documentation around this. Which one do you prefer?

I don't think these necessarily need to be mutually exclusive options. IMO updating the relevant docs would be very beneficial. However, I think we could also consider having a tracking issue that enumerates the badges the fine-grained tokens won't work for. Obviously that's out of our control and there's nothing we can do one way or another, but a single, simple issue that lists those out which we could both (a) link to from the aforementioned new/updated docs and (b) use as a streamlined thread to e.g. post links to feature requests/contact/etc. with GitHub would be helpful

[chris48s]

I've been meaning to do a quick docs PR for this but it has taken a few days to plough through some notifications backlog. I've submitted #8823

This is just conjecture, but my gut instinct is that because a GraphQL API is so 'freeform' it is probably quite a lot more complicated to apply granular permissions to a GraphQL API because a single query might read (or write) data that requires a broad mix of different permissions. A REST API is much more rigid in this respect. Because of that, I can see this limitation that the GraphQL API doesn't support fine-grained PATs being around for a long time, rather than something that gets resolved soon. Maybe I'm wrong. There are lots of smart people at GitHub, but that's my prediction.

Given that, I think we shouldn't list the services that don't work in the docs as it is something that will inevitably fluctuate over time and my guess is we'll end up maintaining that list for quite a long time.