I've been looking into this as I'm building similar per resource scoping for conjure.so's API.
GitHub has 'OAuth Apps' and 'GitHub Apps' [0]. The former's scopes do not permit such granularity (eg the `repo` scope gives access to all repos of the account [1]).
The latter is much more granular, allowing the user to select specific repos to grant permission [2].
The 'GitHub App' owner can see their installations and also determine if the user chose access for all repos or on a per repo basis.
Netlify does such granular installation and will prompt you if you don't see your repo listed in their dashboard to check permissions.
Do you think that still sounds much more confusing than it needs to be?
I don't totally understand why they offer these two mechanisms of integration -- or why the granularity of access would need to be different between them. Why not let "OAuth apps" be authorized per-repo -- if you are going to have "OAuth apps" existing as a thing still? And they don't seem to be deprecated in favor of newer "github apps", right?
Yeah agreed its pretty confusing and took me some time to reconcile!
I imagine for legacy support or business reasons they maintain the OAuth API, but I too wish they add granular repo support to the OAuth API and existing tokens were migrated to an all repos scope, while new tokens were encouraged to be per repo scoping.
I don't totally understand why they offer these two mechanisms of integration -- or why the granularity of access would need to be different between them. Why not let "OAuth apps" be authorized per-repo -- if you are going to have "OAuth apps" existing as a thing still? And they don't seem to be deprecated in favor of newer "github apps", right?