Closes https://github.com/sourcegraph/sourcegraph/issues/53280.

Adds support for installing a Batches domain GitHub App on multiple accounts and then locating the appropriate installation by repo namespace == account name in order to authenticate the ChangesetSource for duplicating and signing commits.

Walkthrough

I'm the master of producing chunky PRs lately so here's another code walkthrough to ease the burden of reviewing this. Remember that more than half the files changed are just for stupid logger plumbing and nothing else. 🙈 We'll go back to front again.

new migrations - [code]

• The first migration adds additional metadata about a GitHub App Installation to the github_app_installs table. It also creates an index based on the account_login, since that's how we'll look up the right install for a given commit signing interaction.
• The second migration adds a unique constraint on for app_id and installation_id. This enables us to easily update records with the same SQL INSERT statement we use to add a new one.

github_apps/store - [code]

• Install now takes a fully formed ghtypes.GitHubAppInstallation as an input and performs an upsert (insert or update) of the record.
• GetLatestInstallID has been replaced with the more relevant GetInstallID, which looks up installations by app ID and account/namespace name and returns the installation ID of the latest record that matches.
• BulkInstall was removed because it was easier to just loop and upsert individual records.
• SyncInstallations is a new method that performs the logic that was originally in the installation backfill worker. This allows us to tap into it in another place. The logic has been enhanced slight as well:
  • We now delete all Installations for an App if that App was not reachable on GitHub.
  • We now add (upsert) records for all Installations returned from the remote request, including existing ones. It upserts them with all the additional metadata.

worker/installation_backfill - [code]

• The worker routine has been simplified to mostly just preparing a GitHub client and then calling store.SyncInstallations. The test has largely been migrated to the store package tests instead.

batches/sources - [code]

• withGitHubAppAuthenticator now takes account as an additional argument and uses it to look up the installation for both the right app ID and account name when creating the installation authenticator.

batches.graphql - [code]

• I replaced our GitHubAppConfiguration type with the same GitHubApp type from the GH Apps GraphQL schema, since we're increasingly needing more and more properties of the App in the Batches space and it was beginning to feel redundant. Now the commitSigningConfiguration field will resolve to a full GitHubApp rather than our shallow copy of one.

anything in frontend/internal/batches

• Almost everything here is literally me just passing a logger or maybe an EnterpriseDB around. It was extremely painful to write, but hopefully less painful to skim. 🙂
• The only exception is code_host.go, where we now nest a githubapp.NewGitHubAppResolver for the commit signing configuration.

graphqlbackend.graphqlbackend.go - [code]

• Because the Batches GraphQL Schema now depends on the GitHub Apps Schema also being available, I updated NewSchemaWithBatchChangesResolver to provide both as resolvers, and updated NewSchema to accept a slice of resolvers instead of just one. This had a bit of a ripple effect in that I had to update everyone who calls this method to call it with a slice now. 😅

githubappauth/resolver.go - [code]

• Originally, to resolve the Installations field on a GitHubApp, this resolver would requery GitHub itself for the Installations every time. Now we take the Installations we have stored in the DB to resolve this field faster.
• We also opportunistically kick of store.SyncInstallations whenever Installations is called, so the set of Installations for the GitHubApp will be updated immediately after if they are out-of-date. This has the added benefit of providing us a way to trigger a "manual sync" of GitHub App Installations if needed.
• This sync process is offloaded to a goroutine so as not to block the GraphQL request from completing.
• Resolving Installations is also now guarded behind a sync.Once mechanism to ensure the function is only executed once for a given GraphQL request.

githubappauth/middleware.go [code]

• The /setup handler will now fetch the whole GitHub App Installation before saving it in the DB, to ensure we can populate all the necessary metadata.

GitHubAppPage - [code]

• This page now has a configurable header breadcrumb.
• Rather than showing the warning banner about being un-editable if it's rendered for a Batches App, now it shows just the parts of the page that are relevant to Batch Changes, namely, the basic App details and the list of Installations registered on Sourcegraph.
• This page is now accessible for Batches domain Apps at /site-admin/batch-changes/github-apps/:id.

Demo

Prior to this PR, we would just pretend that whatever GitHub App installation we had would work for any repositories on that code host. That would mean that publishing changesets on repositories from separate orgs wouldn't just not produce signed commits, it would actually just outright fail to publish.

In the demo, I start out with a new GitHub App, which I only install to my personal user account namespace. I test that when I publish two changesets, one to a repo in my user namespace and one to a repo in the sourcegraph-testing namespace, they both succeed to publish. In this case, the sourcegraph-testing one just falls back on normal batch change user credentials, yielding an unsigned commit but one which is authored by me. However, the courier-new one is able to authenticate with as the GH App installation for that account and duplicate the commit, yielding the signed one!

Then, I make the GH App publish and install it for sourcegraph-testing. I modify the branch name for my batch spec to trigger new changesets to be published and publish the two again. This time, both succeed and have signed commits.

Test plan

Updated unit tests where applicable. Manual testing of the whole flow.