Connecting a GitHub account

Connecting a GitHub account lets Innesta read pull requests and workflow runs for repositories whose remote points at GitHub. That is all it does: every call made with it is read-only, and it is not the credential Git uses when it fetches and pushes — that one is entered separately and kept as its own Keychain item.

Signing in

The sign-in is OAuth with PKCE, in your default browser. Innesta opens GitHub, you approve, and the callback comes back to the window that started the flow — exactly once, so two windows waiting for a sign-in cannot both claim it.

Your password never reaches Innesta.

Where the token is kept

The access token, and the refresh token where there is one, go into the macOS Keychain. Nowhere else, and not in a preferences file.

GitHub.com and GitHub Enterprise Server

GitHub.com uses OAuth as described. The client id is built in and the app secret is injected into the released build, so there is nothing to register.

GitHub Enterprise Server works through the API with a manual provider token that you supply. It does not do OAuth, and it does not reuse the GitHub.com credentials — those are registered for GitHub.com and are not valid against another host. Making that token and saving it where Innesta looks for it is a page of its own.

Remotes on a domain of their own

Provider detection reads the remote’s URL. A GitHub instance on a custom domain will not be recognised, so you can set the provider for that remote by hand; the choice is remembered per remote.

When something goes wrong

Innesta distinguishes the kinds of failure rather than reporting one error for all of them, because they need different responses:

• authentication expired or rejected — sign in again;
• access denied — the account is fine and cannot see that repository;
• rate limited — wait;
• invalid response — the server said something unexpected.