Self-hosted GitLab and GitHub Enterprise Server

Registering the application on a server of your own, and the fields Innesta needs afterwards.

A server of your own is supported, and the two products do not go about it the same way.

Self-Managed and Dedicated GitLab does OAuth: you register an application on your instance and Innesta signs in through the browser, as it does for GitLab.com. GitHub Enterprise Server does not — Innesta never sends its GitHub.com client id or secret to another host, so Enterprise Server is read through the API with a token you make yourself.

Either way you get the same thing: read-only merge and pull requests and pipelines, and not the credential Git fetches and pushes with.

Setting the provider

Detection reads the remote’s URL and knows a fixed list of hosts: github.com, gitlab.com and its subdomains, bitbucket.org, and the Azure DevOps hosts. Your server is on a domain of your own, so Innesta will not place it — which is why both halves of this page start here.

Open the gear beside the repository’s name, then Remotes.
Click the remote’s row to select it, if there is more than one.
The badge at the right-hand end of the row reads Automatic on a remote Innesta could not place, and it is a menu: set it to GitLab or GitHub.

The choice is remembered for that remote. The menu is there only on a remote Innesta could not place — the rest carry a plain badge naming the host that was recognised, and there is nothing to decide.

GitLab: register the application

On your instance, register a non-confidential application. GitLab allows these at user, group and instance level, and which you may use is your instance’s policy; its own OAuth 2.0 provider page says where each one is.

Field	Value
Name	anything; `Innesta` is the obvious choice
Redirect URI	`app.innesta.git-client://oauth/gitlab`
Confidential	unticked
Scopes	`read_api`, and nothing else — it covers every read Innesta makes

The redirect URI is matched character for character. It is not an https:// address but a private-use scheme registered by the app, which is how the browser hands the answer back.

Saving gives you an Application ID: that is the client id Innesta asks for. Whatever secret the page also offers, Innesta neither asks for one nor sends one — the GitLab flow proves itself with PKCE instead.

GitLab: fill in the two fields

Back in Remotes, with the remote selected and its provider set to GitLab, an OAuth section has appeared.

Instance URL — the complete base URL of your instance.
Client ID — the Application ID.
Save.
Connect. The browser opens, you approve, and the answer comes back to the window that started it.
Status reads OAuth connected — automatic renewal.

The base URL is checked when you press Save, and it has to be https even when the remote is ssh:// or git@…, on the remote’s own host, with the port if that is not 443, and with no username, password, query or fragment.

It also has to be a prefix of the remote’s URL, path included: a remote at https://example.com/gitlab/team/kettle.git wants https://example.com/gitlab, which is how Innesta knows the project is team/kettle. Get it wrong and the app says so in those words. The arrow beside the field puts back the instance it worked out from the remote itself.

Editing the Instance URL or Client ID of an instance you are already connected to re-authorises nothing by itself: Save asks you to reconnect, and the button beside it now reads Reconnect.

Enterprise Server: make a token

Nothing to register, because there is no OAuth. Innesta needs a personal access token that can read the pull requests, workflow runs and job logs you want to see — in practice repo for anything in a private repository, which GitHub defines as full access to public and private repositories. That is wider than Innesta uses, and the same compromise the GitHub.com sign-in makes, since OAuth apps have no read-only equivalent for private repositories.

The difference is that this token is yours to write rather than a scope you consent to, so make it as narrow as your server allows. Innesta only reads: there are no provider writes in the app at all.

Enterprise Server: save the token

It goes into the macOS Keychain through the Accounts tab, and two of the fields have to be exactly right.

Innesta ▸ Settings… (⌘,) → Accounts.
Under Keychain Credential, choose Provider API Token.
Host — the host as it appears in the remote’s URL and nothing else: git.example.com, not https://git.example.com/team/kettle.git. Add :port only if the remote’s URL carries one.
Account — oauth, literally. Not your username and not a label you may choose: it is the name Innesta looks the item up under, so a token filed under anything else is one the app will never find.
Password or Token — the token.
Save.

Innesta takes it over on the next provider request and files it as a manual token, which is never refreshed because there is nothing to refresh it with. The item you typed disappears from the Keychain when that happens.

Knowing whether it worked

For GitLab, Status says so. Enterprise Server has no such row: in place of the OAuth section, Remotes shows Provider Access — a note that OAuth is unsupported here and a reminder of where the token goes. Nothing to connect, so nothing to report; the token has worked when Pull Requests in the sidebar starts filling.

Verify on the Accounts tab proves less than it looks. It reports Credential found, which is exactly what it checked — the Keychain holds an item under that host and account. It does not contact your server; only Test Access, which belongs to the Git HTTPS Credential Git pushes with, goes near the network.

When it does not work

Connect is unavailable. It wants an Instance URL, and on your own instance a Client ID too. It is also unavailable while another operation is running.
The browser opens and nothing comes back. The application’s redirect URI is not app.innesta.git-client://oauth/gitlab, exactly.
Status reads Reconnection required. Press Reconnect. Innesta does not delete a credential over one error, so waiting has cost nothing.
Access denied rather than an expired sign-in. The account is fine and cannot see that project; Innesta tells the two apart because they need different answers.