Add support for the new fine-grained github tokens

[kahoot-karl]

This would be great to support :)

[villeodell]

I did some digging on this and wanted to share what I found in case it's useful.

What I tested

I tried playing around with a fine-grained PAT with Pull requests (read), Commit statuses (read), Metadata (read), and Contents (read) - with Build Information in Pullbar set to "none." but couldn't get it to work.

What I found

GitHub added GraphQL support for fine-grained PATs in April 2023 but there still seem to be edge cases. They say remaining gaps "will be solved over time" but no timeline and I didn't see anything on GitHub Public Roadmap (view).

https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens#fine-grained-personal-access-tokens-limitations:

Fine-grained personal access tokens do not support every feature of personal access tokens (classic). These feature gaps are not permanent - GitHub is working to close them. You can review our public roadmap for more details on when these scenarios will be supported.

The major gaps in fine-grained personal access tokens are:

• Using fine-grained personal access token to contribute to public repos where the user is not a member.
• Using fine-grained personal access token to contribute to repositories where the user is an outside or repository collaborator.
• Using fine-grained personal access token to access multiple organizations at once.
• Using fine-grained personal access token to access Packages.
• Using fine-grained personal access token to call the Checks API.
• Using fine-grained personal access token to access Projects owned by a user account.

All of these gaps will be solved over time, as GitHub continues to invest in more secure access patterns.

I guess PullBar uses Checks API?

Interesting data point

I found another (closed-source) menubar PR app that works with fine-grained PATs using just Actions (read) permission. That suggests it might be using REST API endpoints (/repos/{owner}/{repo}/pulls, /repos/{owner}/{repo}/actions/runs) rather than GraphQL.

So switching to REST might be a path if GraphQL continues to be problematic - though I'm sure that's a bigger change.

---

Hope this is helpful!