Summary

Add GitHub App connectivity.

Review Request #15144 — Created June 30, 2026 and updated July 27, 2026, 12:57 a.m.

Information

Owner

david

Repository

Review Board

Branch

release-9.x

Bugs

Depends On

Reviewers

Groups

reviewboard

People

Description

This change adds a GitHub App as an alternative to Personal Access
Tokens. This involves a bunch of moving parts:

The actual GitHub App backend, which includes a redirect view that
will trigger the GitHub App Manifest flow, and callback views for
when the app has been created and when the app has been installed
into a user or organization. This ends up creating a hidden
HostingServiceAccount which holds the app registration keys, and
then each time the app gets installed (for a user or organization)
will create a new HostingServiceAccount for that entry.
Modifications to the GitHub client to use the app for authentication.
This involves minting short-lived RS256 JWT tokens for the actual API
requests to GitHub.
Customized UI parts for the connected services list. This involves:

Special templates and flows for the "Connect a service" wizard which
lets users choose how they want to connect, and triggers for the new
app creation flow.
An override for the entry template which adds an extra controls
panel that either encourages users to create the app (if they have
existing connections using PATs only), or provides a link into
GitHub's settings UI (allowing changes to URLs or transferring the
app registration to another owner).

This also currently includes a stub webhook handler (since GitHub Apps
have a single webhook endpoint for all authorized repositories), as well
as some commented-out bits for future enhancement.

Testing Done


Connected a GitHub App and installed it into multiple organizations.
Tested all aspects of the wizard flow, including creation of the app

  and reassignment of any PAT-based repositories after app install.
Verified that API access works correctly when authenticating using the

  app tokens.
Ran unit tests.

Commits

Summary	ID
Add GitHub App connectivity. This change adds a GitHub App as an alternative to Personal Access Tokens. This involves a bunch of moving parts: 1. The actual GitHub App backend, which includes a redirect view that will trigger the GitHub App Manifest flow, and callback views for when the app has been created and when the app has been installed into a user or organization. This ends up creating a hidden `HostingServiceAccount` which holds the app registration keys, and then each time the app gets installed (for a user or organization) will create a new `HostingServiceAccount` for that entry. 2. Modifications to the GitHub client to use the app for authentication. This involves minting short-lived RS256 JWT tokens for the actual API requests to GitHub. 3. Customized UI parts for the connected services list. This involves: - Special templates and flows for the "Connect a service" wizard which lets users choose how they want to connect, and triggers for the new app creation flow. - An override for the entry template which adds an extra controls panel that either encourages users to create the app (if they have existing connections using PATs only), or provides a link into GitHub's settings UI (allowing changes to URLs or transferring the app registration to another owner). This also currently includes a stub webhook handler (since GitHub Apps have a single webhook endpoint for all authorized repositories), as well as some commented-out bits for future enhancement. Testing Done: - Connected a GitHub App and installed it into multiple organizations. - Tested all aspects of the wizard flow, including creation of the app and reassignment of any PAT-based repositories after app install. - Verified that API access works correctly when authenticating using the app tokens. - Ran unit tests.	qmxulzkloxrsnquyqwrxwlrrquzplqpr

Summary

Add GitHub App connectivity.

This change adds a GitHub App as an alternative to Personal Access Tokens. This involves a bunch of moving parts: 1. The actual GitHub App backend, which includes a redirect view that will trigger the GitHub App Manifest flow, and callback views for when the app has been created and when the app has been installed into a user or organization. This ends up creating a hidden `HostingServiceAccount` which holds the app registration keys, and then each time the app gets installed (for a user or organization) will create a new `HostingServiceAccount` for that entry. 2. Modifications to the GitHub client to use the app for authentication. This involves minting short-lived RS256 JWT tokens for the actual API requests to GitHub. 3. Customized UI parts for the connected services list. This involves: - Special templates and flows for the "Connect a service" wizard which lets users choose how they want to connect, and triggers for the new app creation flow. - An override for the entry template which adds an extra controls panel that either encourages users to create the app (if they have existing connections using PATs only), or provides a link into GitHub's settings UI (allowing changes to URLs or transferring the app registration to another owner). This also currently includes a stub webhook handler (since GitHub Apps have a single webhook endpoint for all authorized repositories), as well as some commented-out bits for future enhancement. Testing Done: - Connected a GitHub App and installed it into multiple organizations. - Tested all aspects of the wizard flow, including creation of the app and reassignment of any PAT-based repositories after app install. - Verified that API access works correctly when authenticating using the app tokens. - Ran unit tests.

qmxulzkloxrsnquyqwrxwlrrquzplqpr

Files

Issues

Description	From	Last Updated
Can we make a pydantic model for the GitHub app data (the github_app data stored on the installation account)?	maubin	July 23, 2026, 8:55 p.m.
Ok so thinking about local sites again (this is on my mind from neglecting to really consider local sites when …	maubin	July 24, 2026, 10:26 a.m.
Do we nicely handle things if there's a lot of repositories here? Like having a vertical scrollbar if there's a …	maubin	July 23, 2026, 8:37 a.m.
continuation line under-indented for visual indent Column: 34 Error code: E128	reviewbot	June 30, 2026, 2:56 p.m.
'reviewboard.site.models.LocalSite' imported but unused Column: 5 Error code: F401	reviewbot	July 17, 2026, 12:02 p.m.
Can we rename to AppManifestResponse.	maubin	July 23, 2026, 8:26 a.m.
Can we rename to InstallationAccountResponse.	maubin	July 23, 2026, 8:24 a.m.
Can you add a Version Added to this.	maubin	July 23, 2026, 8:29 a.m.
In this change the App views were put into reviewboard.hostingsvcs.github.views and I don't see any other changes where you split …	maubin	July 23, 2026, 8:29 a.m.
This needs a Version Added.	maubin	July 23, 2026, 8:29 a.m.
Should we pass local_site=request.get('local_site') here?	maubin	July 23, 2026, 8:31 a.m.
I think there will always be a request.local_site attribute because of our LocalSiteMiddleware.	maubin	July 23, 2026, 8:32 a.m.
Same note about request.local_site always existing.	maubin	July 23, 2026, 8:32 a.m.
line too long (87 > 79 characters) Column: 80 Error code: E501	reviewbot	July 23, 2026, 9:57 a.m.
line too long (85 > 79 characters) Column: 80 Error code: E501	reviewbot	July 23, 2026, 9:57 a.m.
Missing a docstring.	maubin	July 24, 2026, 9:25 a.m.
Could this be Literal['user', 'organization', '']?	maubin	July 24, 2026, 9:26 a.m.
Same comment as above.	maubin	July 24, 2026, 9:26 a.m.
Seems like this could be Literal['all', 'selected'].	maubin	July 24, 2026, 9:27 a.m.
Can you add a docstring for this.	maubin	July 24, 2026, 10:26 a.m.
This can be removed, we do this below in the if condition.	maubin	July 24, 2026, 9:28 a.m.
We do these isinstance checks on the app data a lot more than we do is_installation_account() or is_app_record_account(). Might be …	maubin	July 24, 2026, 10:23 a.m.
This can be an elif or add back in the blank line before this.	maubin	July 27, 2026, 8:31 a.m.
We can remove local_site here because we do a local_site = app_account.local_site in the view instead of using this value …	maubin	July 24, 2026, 9:51 a.m.
Same comment as above.	maubin	July 24, 2026, 9:51 a.m.
I'm getting a bit mixed up with the namings. We have "app-record accounts" and "installation accounts". A hosting service account …	maubin	July 24, 2026, 9:53 a.m.

flake8 failed.

JSHint passed.

flake8

reviewboard/hostingsvcs/tests/test_github.py (Diff revision 1)
The issue has been dropped. Show all issues
```
continuation line under-indented for visual indent

Column: 34
Error code: E128
```

Commits:

	Summary	ID
	Add GitHub App connectivity. This change adds a GitHub App as an alternative to Personal Access Tokens. This involves a bunch of moving parts: 1. The actual GitHub App backend, which includes a redirect view that will trigger the GitHub App Manifest flow, and callback views for when the app has been created and when the app has been installed into a user or organization. This ends up creating a hidden `HostingServiceAccount` which holds the app registration keys, and then each time the app gets installed (for a user or organization) will create a new `HostingServiceAccount` for that entry. 2. Modifications to the GitHub client to use the app for authentication. This involves minting short-lived RS256 JWT tokens for the actual API requests to GitHub. 3. Customized UI parts for the connected services list. This involves: - Special templates and flows for the "Connect a service" wizard which lets users choose how they want to connect, and triggers for the new app creation flow. - An override for the entry template which adds an extra controls panel that either encourages users to create the app (if they have existing connections using PATs only), or provides a link into GitHub's settings UI (allowing changes to URLs or transferring the app registration to another owner). This also currently includes a stub webhook handler (since GitHub Apps have a single webhook endpoint for all authorized repositories), as well as some commented-out bits for future enhancement. Testing Done: - Connected a GitHub App and installed it into multiple organizations. - Tested all aspects of the wizard flow, including creation of the app and reassignment of any PAT-based repositories after app install. - Verified that API access works correctly when authenticating using the app tokens. - Ran unit tests.	qmxulzkloxrsnquyqwrxwlrrquzplqpr
	Add GitHub App connectivity. This change adds a GitHub App as an alternative to Personal Access Tokens. This involves a bunch of moving parts: 1. The actual GitHub App backend, which includes a redirect view that will trigger the GitHub App Manifest flow, and callback views for when the app has been created and when the app has been installed into a user or organization. This ends up creating a hidden `HostingServiceAccount` which holds the app registration keys, and then each time the app gets installed (for a user or organization) will create a new `HostingServiceAccount` for that entry. 2. Modifications to the GitHub client to use the app for authentication. This involves minting short-lived RS256 JWT tokens for the actual API requests to GitHub. 3. Customized UI parts for the connected services list. This involves: - Special templates and flows for the "Connect a service" wizard which lets users choose how they want to connect, and triggers for the new app creation flow. - An override for the entry template which adds an extra controls panel that either encourages users to create the app (if they have existing connections using PATs only), or provides a link into GitHub's settings UI (allowing changes to URLs or transferring the app registration to another owner). This also currently includes a stub webhook handler (since GitHub Apps have a single webhook endpoint for all authorized repositories), as well as some commented-out bits for future enhancement. Testing Done: - Connected a GitHub App and installed it into multiple organizations. - Tested all aspects of the wizard flow, including creation of the app and reassignment of any PAT-based repositories after app install. - Verified that API access works correctly when authenticating using the app tokens. - Ran unit tests.	qmxulzkloxrsnquyqwrxwlrrquzplqpr

Diff:

Revision 2 (+7694 -50)

Show changes

	reviewboard/admin/views.py
	reviewboard/admin/tests/test_connect_service_view.py
	reviewboard/admin/tests/test_connected_services_list_view.py
	reviewboard/hostingsvcs/github/accounts.py
	reviewboard/hostingsvcs/github/api.py
	reviewboard/hostingsvcs/github/app_auth.py
	reviewboard/hostingsvcs/github/client.py
	reviewboard/hostingsvcs/github/service.py
	10 more

Checks run (2 succeeded)

flake8 passed.

JSHint passed.

Change Summary:


Match accounts based on numeric ID, which stays constant across account renames.
Make is_authorized() return True for GitHub App HostingServiceAccounts.

Commits:

	Summary	ID
	Add GitHub App connectivity. This change adds a GitHub App as an alternative to Personal Access Tokens. This involves a bunch of moving parts: 1. The actual GitHub App backend, which includes a redirect view that will trigger the GitHub App Manifest flow, and callback views for when the app has been created and when the app has been installed into a user or organization. This ends up creating a hidden `HostingServiceAccount` which holds the app registration keys, and then each time the app gets installed (for a user or organization) will create a new `HostingServiceAccount` for that entry. 2. Modifications to the GitHub client to use the app for authentication. This involves minting short-lived RS256 JWT tokens for the actual API requests to GitHub. 3. Customized UI parts for the connected services list. This involves: - Special templates and flows for the "Connect a service" wizard which lets users choose how they want to connect, and triggers for the new app creation flow. - An override for the entry template which adds an extra controls panel that either encourages users to create the app (if they have existing connections using PATs only), or provides a link into GitHub's settings UI (allowing changes to URLs or transferring the app registration to another owner). This also currently includes a stub webhook handler (since GitHub Apps have a single webhook endpoint for all authorized repositories), as well as some commented-out bits for future enhancement. Testing Done: - Connected a GitHub App and installed it into multiple organizations. - Tested all aspects of the wizard flow, including creation of the app and reassignment of any PAT-based repositories after app install. - Verified that API access works correctly when authenticating using the app tokens. - Ran unit tests.	qmxulzkloxrsnquyqwrxwlrrquzplqpr
	Add GitHub App connectivity. This change adds a GitHub App as an alternative to Personal Access Tokens. This involves a bunch of moving parts: 1. The actual GitHub App backend, which includes a redirect view that will trigger the GitHub App Manifest flow, and callback views for when the app has been created and when the app has been installed into a user or organization. This ends up creating a hidden `HostingServiceAccount` which holds the app registration keys, and then each time the app gets installed (for a user or organization) will create a new `HostingServiceAccount` for that entry. 2. Modifications to the GitHub client to use the app for authentication. This involves minting short-lived RS256 JWT tokens for the actual API requests to GitHub. 3. Customized UI parts for the connected services list. This involves: - Special templates and flows for the "Connect a service" wizard which lets users choose how they want to connect, and triggers for the new app creation flow. - An override for the entry template which adds an extra controls panel that either encourages users to create the app (if they have existing connections using PATs only), or provides a link into GitHub's settings UI (allowing changes to URLs or transferring the app registration to another owner). This also currently includes a stub webhook handler (since GitHub Apps have a single webhook endpoint for all authorized repositories), as well as some commented-out bits for future enhancement. Testing Done: - Connected a GitHub App and installed it into multiple organizations. - Tested all aspects of the wizard flow, including creation of the app and reassignment of any PAT-based repositories after app install. - Verified that API access works correctly when authenticating using the app tokens. - Ran unit tests.	qmxulzkloxrsnquyqwrxwlrrquzplqpr

Diff:

Revision 3 (+7994 -50)

Show changes

	reviewboard/admin/views.py
	reviewboard/admin/tests/test_connect_service_view.py
	reviewboard/admin/tests/test_connected_services_list_view.py
	reviewboard/hostingsvcs/github/accounts.py
	reviewboard/hostingsvcs/github/api.py
	reviewboard/hostingsvcs/github/app_auth.py
	reviewboard/hostingsvcs/github/client.py
	reviewboard/hostingsvcs/github/service.py
	10 more

Checks run (2 succeeded)

flake8 passed.

JSHint passed.

Change Summary:


Rebase on top of /r/15169/
Redirect correctly back to connect wizard after app install.

Commits:

	Summary	ID
	Add GitHub App connectivity. This change adds a GitHub App as an alternative to Personal Access Tokens. This involves a bunch of moving parts: 1. The actual GitHub App backend, which includes a redirect view that will trigger the GitHub App Manifest flow, and callback views for when the app has been created and when the app has been installed into a user or organization. This ends up creating a hidden `HostingServiceAccount` which holds the app registration keys, and then each time the app gets installed (for a user or organization) will create a new `HostingServiceAccount` for that entry. 2. Modifications to the GitHub client to use the app for authentication. This involves minting short-lived RS256 JWT tokens for the actual API requests to GitHub. 3. Customized UI parts for the connected services list. This involves: - Special templates and flows for the "Connect a service" wizard which lets users choose how they want to connect, and triggers for the new app creation flow. - An override for the entry template which adds an extra controls panel that either encourages users to create the app (if they have existing connections using PATs only), or provides a link into GitHub's settings UI (allowing changes to URLs or transferring the app registration to another owner). This also currently includes a stub webhook handler (since GitHub Apps have a single webhook endpoint for all authorized repositories), as well as some commented-out bits for future enhancement. Testing Done: - Connected a GitHub App and installed it into multiple organizations. - Tested all aspects of the wizard flow, including creation of the app and reassignment of any PAT-based repositories after app install. - Verified that API access works correctly when authenticating using the app tokens. - Ran unit tests.	qmxulzkloxrsnquyqwrxwlrrquzplqpr
	Add GitHub App connectivity. This change adds a GitHub App as an alternative to Personal Access Tokens. This involves a bunch of moving parts: 1. The actual GitHub App backend, which includes a redirect view that will trigger the GitHub App Manifest flow, and callback views for when the app has been created and when the app has been installed into a user or organization. This ends up creating a hidden `HostingServiceAccount` which holds the app registration keys, and then each time the app gets installed (for a user or organization) will create a new `HostingServiceAccount` for that entry. 2. Modifications to the GitHub client to use the app for authentication. This involves minting short-lived RS256 JWT tokens for the actual API requests to GitHub. 3. Customized UI parts for the connected services list. This involves: - Special templates and flows for the "Connect a service" wizard which lets users choose how they want to connect, and triggers for the new app creation flow. - An override for the entry template which adds an extra controls panel that either encourages users to create the app (if they have existing connections using PATs only), or provides a link into GitHub's settings UI (allowing changes to URLs or transferring the app registration to another owner). This also currently includes a stub webhook handler (since GitHub Apps have a single webhook endpoint for all authorized repositories), as well as some commented-out bits for future enhancement. Testing Done: - Connected a GitHub App and installed it into multiple organizations. - Tested all aspects of the wizard flow, including creation of the app and reassignment of any PAT-based repositories after app install. - Verified that API access works correctly when authenticating using the app tokens. - Ran unit tests.	qmxulzkloxrsnquyqwrxwlrrquzplqpr

Diff:

Revision 4 (+8108 -44)

Show changes

	reviewboard/admin/views.py
	reviewboard/admin/tests/test_connect_service_view.py
	reviewboard/admin/tests/test_connected_services_list_view.py
	reviewboard/hostingsvcs/github/accounts.py
	reviewboard/hostingsvcs/github/api.py
	reviewboard/hostingsvcs/github/app_auth.py
	reviewboard/hostingsvcs/github/client.py
	reviewboard/hostingsvcs/github/service.py
	13 more

Checks run (2 succeeded)

flake8 passed.

JSHint passed.

Commits:

	Summary	ID
	Add GitHub App connectivity. This change adds a GitHub App as an alternative to Personal Access Tokens. This involves a bunch of moving parts: 1. The actual GitHub App backend, which includes a redirect view that will trigger the GitHub App Manifest flow, and callback views for when the app has been created and when the app has been installed into a user or organization. This ends up creating a hidden `HostingServiceAccount` which holds the app registration keys, and then each time the app gets installed (for a user or organization) will create a new `HostingServiceAccount` for that entry. 2. Modifications to the GitHub client to use the app for authentication. This involves minting short-lived RS256 JWT tokens for the actual API requests to GitHub. 3. Customized UI parts for the connected services list. This involves: - Special templates and flows for the "Connect a service" wizard which lets users choose how they want to connect, and triggers for the new app creation flow. - An override for the entry template which adds an extra controls panel that either encourages users to create the app (if they have existing connections using PATs only), or provides a link into GitHub's settings UI (allowing changes to URLs or transferring the app registration to another owner). This also currently includes a stub webhook handler (since GitHub Apps have a single webhook endpoint for all authorized repositories), as well as some commented-out bits for future enhancement. Testing Done: - Connected a GitHub App and installed it into multiple organizations. - Tested all aspects of the wizard flow, including creation of the app and reassignment of any PAT-based repositories after app install. - Verified that API access works correctly when authenticating using the app tokens. - Ran unit tests.	qmxulzkloxrsnquyqwrxwlrrquzplqpr
	Add GitHub App connectivity. This change adds a GitHub App as an alternative to Personal Access Tokens. This involves a bunch of moving parts: 1. The actual GitHub App backend, which includes a redirect view that will trigger the GitHub App Manifest flow, and callback views for when the app has been created and when the app has been installed into a user or organization. This ends up creating a hidden `HostingServiceAccount` which holds the app registration keys, and then each time the app gets installed (for a user or organization) will create a new `HostingServiceAccount` for that entry. 2. Modifications to the GitHub client to use the app for authentication. This involves minting short-lived RS256 JWT tokens for the actual API requests to GitHub. 3. Customized UI parts for the connected services list. This involves: - Special templates and flows for the "Connect a service" wizard which lets users choose how they want to connect, and triggers for the new app creation flow. - An override for the entry template which adds an extra controls panel that either encourages users to create the app (if they have existing connections using PATs only), or provides a link into GitHub's settings UI (allowing changes to URLs or transferring the app registration to another owner). This also currently includes a stub webhook handler (since GitHub Apps have a single webhook endpoint for all authorized repositories), as well as some commented-out bits for future enhancement. Testing Done: - Connected a GitHub App and installed it into multiple organizations. - Tested all aspects of the wizard flow, including creation of the app and reassignment of any PAT-based repositories after app install. - Verified that API access works correctly when authenticating using the app tokens. - Ran unit tests.	qmxulzkloxrsnquyqwrxwlrrquzplqpr

Diff:

Revision 5 (+8106 -44)

Show changes

	reviewboard/admin/views.py
	reviewboard/admin/tests/test_connect_service_view.py
	reviewboard/admin/tests/test_connected_services_list_view.py
	reviewboard/hostingsvcs/github/accounts.py
	reviewboard/hostingsvcs/github/api.py
	reviewboard/hostingsvcs/github/app_auth.py
	reviewboard/hostingsvcs/github/client.py
	reviewboard/hostingsvcs/github/service.py
	13 more

Checks run (2 succeeded)

flake8 passed.

JSHint passed.

Change Summary:

Update for renamed and changed APIs

Commits:

	Summary	ID
	Add GitHub App connectivity. This change adds a GitHub App as an alternative to Personal Access Tokens. This involves a bunch of moving parts: 1. The actual GitHub App backend, which includes a redirect view that will trigger the GitHub App Manifest flow, and callback views for when the app has been created and when the app has been installed into a user or organization. This ends up creating a hidden `HostingServiceAccount` which holds the app registration keys, and then each time the app gets installed (for a user or organization) will create a new `HostingServiceAccount` for that entry. 2. Modifications to the GitHub client to use the app for authentication. This involves minting short-lived RS256 JWT tokens for the actual API requests to GitHub. 3. Customized UI parts for the connected services list. This involves: - Special templates and flows for the "Connect a service" wizard which lets users choose how they want to connect, and triggers for the new app creation flow. - An override for the entry template which adds an extra controls panel that either encourages users to create the app (if they have existing connections using PATs only), or provides a link into GitHub's settings UI (allowing changes to URLs or transferring the app registration to another owner). This also currently includes a stub webhook handler (since GitHub Apps have a single webhook endpoint for all authorized repositories), as well as some commented-out bits for future enhancement. Testing Done: - Connected a GitHub App and installed it into multiple organizations. - Tested all aspects of the wizard flow, including creation of the app and reassignment of any PAT-based repositories after app install. - Verified that API access works correctly when authenticating using the app tokens. - Ran unit tests.	qmxulzkloxrsnquyqwrxwlrrquzplqpr
	Add GitHub App connectivity. This change adds a GitHub App as an alternative to Personal Access Tokens. This involves a bunch of moving parts: 1. The actual GitHub App backend, which includes a redirect view that will trigger the GitHub App Manifest flow, and callback views for when the app has been created and when the app has been installed into a user or organization. This ends up creating a hidden `HostingServiceAccount` which holds the app registration keys, and then each time the app gets installed (for a user or organization) will create a new `HostingServiceAccount` for that entry. 2. Modifications to the GitHub client to use the app for authentication. This involves minting short-lived RS256 JWT tokens for the actual API requests to GitHub. 3. Customized UI parts for the connected services list. This involves: - Special templates and flows for the "Connect a service" wizard which lets users choose how they want to connect, and triggers for the new app creation flow. - An override for the entry template which adds an extra controls panel that either encourages users to create the app (if they have existing connections using PATs only), or provides a link into GitHub's settings UI (allowing changes to URLs or transferring the app registration to another owner). This also currently includes a stub webhook handler (since GitHub Apps have a single webhook endpoint for all authorized repositories), as well as some commented-out bits for future enhancement. Testing Done: - Connected a GitHub App and installed it into multiple organizations. - Tested all aspects of the wizard flow, including creation of the app and reassignment of any PAT-based repositories after app install. - Verified that API access works correctly when authenticating using the app tokens. - Ran unit tests.	qmxulzkloxrsnquyqwrxwlrrquzplqpr

Diff:

Revision 6 (+8094 -44)

Show changes

	reviewboard/admin/views.py
	reviewboard/admin/tests/test_connect_service_view.py
	reviewboard/admin/tests/test_connected_services_list_view.py
	reviewboard/hostingsvcs/github/accounts.py
	reviewboard/hostingsvcs/github/api.py
	reviewboard/hostingsvcs/github/app_auth.py
	reviewboard/hostingsvcs/github/client.py
	reviewboard/hostingsvcs/github/service.py
	13 more

Checks run (1 failed, 1 succeeded)

flake8 failed.

JSHint passed.

flake8

reviewboard/hostingsvcs/github/service.py (Diff revision 6)
The issue has been dropped. Show all issues
```
'reviewboard.site.models.LocalSite' imported but unused

Column: 5
Error code: F401
```

Commits:

	Summary	ID
	Add GitHub App connectivity. This change adds a GitHub App as an alternative to Personal Access Tokens. This involves a bunch of moving parts: 1. The actual GitHub App backend, which includes a redirect view that will trigger the GitHub App Manifest flow, and callback views for when the app has been created and when the app has been installed into a user or organization. This ends up creating a hidden `HostingServiceAccount` which holds the app registration keys, and then each time the app gets installed (for a user or organization) will create a new `HostingServiceAccount` for that entry. 2. Modifications to the GitHub client to use the app for authentication. This involves minting short-lived RS256 JWT tokens for the actual API requests to GitHub. 3. Customized UI parts for the connected services list. This involves: - Special templates and flows for the "Connect a service" wizard which lets users choose how they want to connect, and triggers for the new app creation flow. - An override for the entry template which adds an extra controls panel that either encourages users to create the app (if they have existing connections using PATs only), or provides a link into GitHub's settings UI (allowing changes to URLs or transferring the app registration to another owner). This also currently includes a stub webhook handler (since GitHub Apps have a single webhook endpoint for all authorized repositories), as well as some commented-out bits for future enhancement. Testing Done: - Connected a GitHub App and installed it into multiple organizations. - Tested all aspects of the wizard flow, including creation of the app and reassignment of any PAT-based repositories after app install. - Verified that API access works correctly when authenticating using the app tokens. - Ran unit tests.	qmxulzkloxrsnquyqwrxwlrrquzplqpr
	Add GitHub App connectivity. This change adds a GitHub App as an alternative to Personal Access Tokens. This involves a bunch of moving parts: 1. The actual GitHub App backend, which includes a redirect view that will trigger the GitHub App Manifest flow, and callback views for when the app has been created and when the app has been installed into a user or organization. This ends up creating a hidden `HostingServiceAccount` which holds the app registration keys, and then each time the app gets installed (for a user or organization) will create a new `HostingServiceAccount` for that entry. 2. Modifications to the GitHub client to use the app for authentication. This involves minting short-lived RS256 JWT tokens for the actual API requests to GitHub. 3. Customized UI parts for the connected services list. This involves: - Special templates and flows for the "Connect a service" wizard which lets users choose how they want to connect, and triggers for the new app creation flow. - An override for the entry template which adds an extra controls panel that either encourages users to create the app (if they have existing connections using PATs only), or provides a link into GitHub's settings UI (allowing changes to URLs or transferring the app registration to another owner). This also currently includes a stub webhook handler (since GitHub Apps have a single webhook endpoint for all authorized repositories), as well as some commented-out bits for future enhancement. Testing Done: - Connected a GitHub App and installed it into multiple organizations. - Tested all aspects of the wizard flow, including creation of the app and reassignment of any PAT-based repositories after app install. - Verified that API access works correctly when authenticating using the app tokens. - Ran unit tests.	qmxulzkloxrsnquyqwrxwlrrquzplqpr

Diff:

Revision 7 (+8092 -44)

Show changes

	reviewboard/admin/views.py
	reviewboard/admin/tests/test_connect_service_view.py
	reviewboard/admin/tests/test_connected_services_list_view.py
	reviewboard/hostingsvcs/github/accounts.py
	reviewboard/hostingsvcs/github/api.py
	reviewboard/hostingsvcs/github/app_auth.py
	reviewboard/hostingsvcs/github/client.py
	reviewboard/hostingsvcs/github/service.py
	13 more

Checks run (2 succeeded)

flake8 passed.

JSHint passed.

Commits:

	Summary	ID
	Add GitHub App connectivity. This change adds a GitHub App as an alternative to Personal Access Tokens. This involves a bunch of moving parts: 1. The actual GitHub App backend, which includes a redirect view that will trigger the GitHub App Manifest flow, and callback views for when the app has been created and when the app has been installed into a user or organization. This ends up creating a hidden `HostingServiceAccount` which holds the app registration keys, and then each time the app gets installed (for a user or organization) will create a new `HostingServiceAccount` for that entry. 2. Modifications to the GitHub client to use the app for authentication. This involves minting short-lived RS256 JWT tokens for the actual API requests to GitHub. 3. Customized UI parts for the connected services list. This involves: - Special templates and flows for the "Connect a service" wizard which lets users choose how they want to connect, and triggers for the new app creation flow. - An override for the entry template which adds an extra controls panel that either encourages users to create the app (if they have existing connections using PATs only), or provides a link into GitHub's settings UI (allowing changes to URLs or transferring the app registration to another owner). This also currently includes a stub webhook handler (since GitHub Apps have a single webhook endpoint for all authorized repositories), as well as some commented-out bits for future enhancement. Testing Done: - Connected a GitHub App and installed it into multiple organizations. - Tested all aspects of the wizard flow, including creation of the app and reassignment of any PAT-based repositories after app install. - Verified that API access works correctly when authenticating using the app tokens. - Ran unit tests.	qmxulzkloxrsnquyqwrxwlrrquzplqpr
	Add GitHub App connectivity. This change adds a GitHub App as an alternative to Personal Access Tokens. This involves a bunch of moving parts: 1. The actual GitHub App backend, which includes a redirect view that will trigger the GitHub App Manifest flow, and callback views for when the app has been created and when the app has been installed into a user or organization. This ends up creating a hidden `HostingServiceAccount` which holds the app registration keys, and then each time the app gets installed (for a user or organization) will create a new `HostingServiceAccount` for that entry. 2. Modifications to the GitHub client to use the app for authentication. This involves minting short-lived RS256 JWT tokens for the actual API requests to GitHub. 3. Customized UI parts for the connected services list. This involves: - Special templates and flows for the "Connect a service" wizard which lets users choose how they want to connect, and triggers for the new app creation flow. - An override for the entry template which adds an extra controls panel that either encourages users to create the app (if they have existing connections using PATs only), or provides a link into GitHub's settings UI (allowing changes to URLs or transferring the app registration to another owner). This also currently includes a stub webhook handler (since GitHub Apps have a single webhook endpoint for all authorized repositories), as well as some commented-out bits for future enhancement. Testing Done: - Connected a GitHub App and installed it into multiple organizations. - Tested all aspects of the wizard flow, including creation of the app and reassignment of any PAT-based repositories after app install. - Verified that API access works correctly when authenticating using the app tokens. - Ran unit tests.	qmxulzkloxrsnquyqwrxwlrrquzplqpr

Diff:

Revision 8 (+8088 -44)

Show changes

	reviewboard/admin/views.py
	reviewboard/admin/tests/test_connect_service_view.py
	reviewboard/admin/tests/test_connected_services_list_view.py
	reviewboard/hostingsvcs/github/accounts.py
	reviewboard/hostingsvcs/github/api.py
	reviewboard/hostingsvcs/github/app_auth.py
	reviewboard/hostingsvcs/github/client.py
	reviewboard/hostingsvcs/github/service.py
	13 more

Checks run (2 succeeded)

flake8 passed.

JSHint passed.

Change Summary:

Do better account lookups for reassigning repos.

Commits:

	Summary	ID
	Add GitHub App connectivity. This change adds a GitHub App as an alternative to Personal Access Tokens. This involves a bunch of moving parts: 1. The actual GitHub App backend, which includes a redirect view that will trigger the GitHub App Manifest flow, and callback views for when the app has been created and when the app has been installed into a user or organization. This ends up creating a hidden `HostingServiceAccount` which holds the app registration keys, and then each time the app gets installed (for a user or organization) will create a new `HostingServiceAccount` for that entry. 2. Modifications to the GitHub client to use the app for authentication. This involves minting short-lived RS256 JWT tokens for the actual API requests to GitHub. 3. Customized UI parts for the connected services list. This involves: - Special templates and flows for the "Connect a service" wizard which lets users choose how they want to connect, and triggers for the new app creation flow. - An override for the entry template which adds an extra controls panel that either encourages users to create the app (if they have existing connections using PATs only), or provides a link into GitHub's settings UI (allowing changes to URLs or transferring the app registration to another owner). This also currently includes a stub webhook handler (since GitHub Apps have a single webhook endpoint for all authorized repositories), as well as some commented-out bits for future enhancement. Testing Done: - Connected a GitHub App and installed it into multiple organizations. - Tested all aspects of the wizard flow, including creation of the app and reassignment of any PAT-based repositories after app install. - Verified that API access works correctly when authenticating using the app tokens. - Ran unit tests.	qmxulzkloxrsnquyqwrxwlrrquzplqpr
	Add GitHub App connectivity. This change adds a GitHub App as an alternative to Personal Access Tokens. This involves a bunch of moving parts: 1. The actual GitHub App backend, which includes a redirect view that will trigger the GitHub App Manifest flow, and callback views for when the app has been created and when the app has been installed into a user or organization. This ends up creating a hidden `HostingServiceAccount` which holds the app registration keys, and then each time the app gets installed (for a user or organization) will create a new `HostingServiceAccount` for that entry. 2. Modifications to the GitHub client to use the app for authentication. This involves minting short-lived RS256 JWT tokens for the actual API requests to GitHub. 3. Customized UI parts for the connected services list. This involves: - Special templates and flows for the "Connect a service" wizard which lets users choose how they want to connect, and triggers for the new app creation flow. - An override for the entry template which adds an extra controls panel that either encourages users to create the app (if they have existing connections using PATs only), or provides a link into GitHub's settings UI (allowing changes to URLs or transferring the app registration to another owner). This also currently includes a stub webhook handler (since GitHub Apps have a single webhook endpoint for all authorized repositories), as well as some commented-out bits for future enhancement. Testing Done: - Connected a GitHub App and installed it into multiple organizations. - Tested all aspects of the wizard flow, including creation of the app and reassignment of any PAT-based repositories after app install. - Verified that API access works correctly when authenticating using the app tokens. - Ran unit tests.	qmxulzkloxrsnquyqwrxwlrrquzplqpr

Diff:

Revision 9 (+8250 -44)

Show changes

	reviewboard/admin/views.py
	reviewboard/admin/tests/test_connect_service_view.py
	reviewboard/admin/tests/test_connected_services_list_view.py
	reviewboard/hostingsvcs/github/accounts.py
	reviewboard/hostingsvcs/github/api.py
	reviewboard/hostingsvcs/github/app_auth.py
	reviewboard/hostingsvcs/github/client.py
	reviewboard/hostingsvcs/github/service.py
	13 more

Checks run (2 succeeded)

flake8 passed.

JSHint passed.

The issue has been resolved. Show all issues

Can we make a pydantic model for the GitHub app data (the github_app data stored on the installation account)?

david

July 23, 2026, 9:55 a.m.

That's a great idea, but I'll need to do it in a separate change because I have a couple other github-related changes in my stack that will also need updating.

david

July 23, 2026, 6:10 p.m.

Changed my mind, merging it into this (and other) changes.

Connect a service - post-install repo reassignment (Revision 1)

The issue has been dropped. Show all issues

Do we nicely handle things if there's a lot of repositories here? Like having a vertical scrollbar if there's a bunch of repositories listed.

david

July 23, 2026, 9:55 a.m.

Yeah, the contents of this dialog are scrollable when necessary.

reviewboard/hostingsvcs/github/api.py (Diff revision 9)
The issue has been resolved. Show all issues
```
Can we rename to AppManifestResponse.
```

reviewboard/hostingsvcs/github/api.py (Diff revision 9)

The issue has been resolved. Show all issues

Can we rename to InstallationAccountResponse.

david

July 23, 2026, 9:55 a.m.

This is actually nested data inside of the Installation (and in a later change, webhook payloads), so it's not a response directly. I can change Installation to InstallationResponse, though.

reviewboard/hostingsvcs/github/client.py (Diff revision 9)
The issue has been resolved. Show all issues
```
Can you add a Version Added to this.
```

reviewboard/hostingsvcs/github/client.py (Diff revision 9)

The issue has been resolved. Show all issues

In this change the App views were put into reviewboard.hostingsvcs.github.views and I don't see any other changes where you split them out into an app_views module.

reviewboard/hostingsvcs/github/service.py (Diff revision 9)
The issue has been resolved. Show all issues
```
This needs a Version Added.
```
reviewboard/hostingsvcs/github/service.py (Diff revision 9)
The issue has been resolved. Show all issues
```
Should we pass local_site=request.get('local_site') here?
```

reviewboard/hostingsvcs/github/service.py (Diff revision 9)

The issue has been resolved. Show all issues

I think there will always be a request.local_site attribute because of our LocalSiteMiddleware.

reviewboard/hostingsvcs/github/views.py (Diff revision 9)
The issue has been resolved. Show all issues
```
Same note about request.local_site always existing.
```

Commits:

	Summary	ID
	Add GitHub App connectivity. This change adds a GitHub App as an alternative to Personal Access Tokens. This involves a bunch of moving parts: 1. The actual GitHub App backend, which includes a redirect view that will trigger the GitHub App Manifest flow, and callback views for when the app has been created and when the app has been installed into a user or organization. This ends up creating a hidden `HostingServiceAccount` which holds the app registration keys, and then each time the app gets installed (for a user or organization) will create a new `HostingServiceAccount` for that entry. 2. Modifications to the GitHub client to use the app for authentication. This involves minting short-lived RS256 JWT tokens for the actual API requests to GitHub. 3. Customized UI parts for the connected services list. This involves: - Special templates and flows for the "Connect a service" wizard which lets users choose how they want to connect, and triggers for the new app creation flow. - An override for the entry template which adds an extra controls panel that either encourages users to create the app (if they have existing connections using PATs only), or provides a link into GitHub's settings UI (allowing changes to URLs or transferring the app registration to another owner). This also currently includes a stub webhook handler (since GitHub Apps have a single webhook endpoint for all authorized repositories), as well as some commented-out bits for future enhancement. Testing Done: - Connected a GitHub App and installed it into multiple organizations. - Tested all aspects of the wizard flow, including creation of the app and reassignment of any PAT-based repositories after app install. - Verified that API access works correctly when authenticating using the app tokens. - Ran unit tests.	qmxulzkloxrsnquyqwrxwlrrquzplqpr
	Add GitHub App connectivity. This change adds a GitHub App as an alternative to Personal Access Tokens. This involves a bunch of moving parts: 1. The actual GitHub App backend, which includes a redirect view that will trigger the GitHub App Manifest flow, and callback views for when the app has been created and when the app has been installed into a user or organization. This ends up creating a hidden `HostingServiceAccount` which holds the app registration keys, and then each time the app gets installed (for a user or organization) will create a new `HostingServiceAccount` for that entry. 2. Modifications to the GitHub client to use the app for authentication. This involves minting short-lived RS256 JWT tokens for the actual API requests to GitHub. 3. Customized UI parts for the connected services list. This involves: - Special templates and flows for the "Connect a service" wizard which lets users choose how they want to connect, and triggers for the new app creation flow. - An override for the entry template which adds an extra controls panel that either encourages users to create the app (if they have existing connections using PATs only), or provides a link into GitHub's settings UI (allowing changes to URLs or transferring the app registration to another owner). This also currently includes a stub webhook handler (since GitHub Apps have a single webhook endpoint for all authorized repositories), as well as some commented-out bits for future enhancement. Testing Done: - Connected a GitHub App and installed it into multiple organizations. - Tested all aspects of the wizard flow, including creation of the app and reassignment of any PAT-based repositories after app install. - Verified that API access works correctly when authenticating using the app tokens. - Ran unit tests.	qmxulzkloxrsnquyqwrxwlrrquzplqpr

Diff:

Revision 10 (+8278 -44)

Show changes

	reviewboard/admin/views.py
	reviewboard/admin/tests/test_connect_service_view.py
	reviewboard/admin/tests/test_connected_services_list_view.py
	reviewboard/hostingsvcs/github/accounts.py
	reviewboard/hostingsvcs/github/api.py
	reviewboard/hostingsvcs/github/app_auth.py
	reviewboard/hostingsvcs/github/client.py
	reviewboard/hostingsvcs/github/service.py
	13 more

Checks run (1 failed, 1 succeeded)

flake8 failed.

JSHint passed.

flake8

reviewboard/hostingsvcs/tests/github/test_app_views.py (Diff revision 10)
The issue has been dropped. Show all issues
```
line too long (87 > 79 characters)

Column: 80
Error code: E501
```
reviewboard/hostingsvcs/tests/github/test_app_views.py (Diff revision 10)
The issue has been dropped. Show all issues
```
line too long (85 > 79 characters)

Column: 80
Error code: E501
```

Commits:

	Summary	ID
	Add GitHub App connectivity. This change adds a GitHub App as an alternative to Personal Access Tokens. This involves a bunch of moving parts: 1. The actual GitHub App backend, which includes a redirect view that will trigger the GitHub App Manifest flow, and callback views for when the app has been created and when the app has been installed into a user or organization. This ends up creating a hidden `HostingServiceAccount` which holds the app registration keys, and then each time the app gets installed (for a user or organization) will create a new `HostingServiceAccount` for that entry. 2. Modifications to the GitHub client to use the app for authentication. This involves minting short-lived RS256 JWT tokens for the actual API requests to GitHub. 3. Customized UI parts for the connected services list. This involves: - Special templates and flows for the "Connect a service" wizard which lets users choose how they want to connect, and triggers for the new app creation flow. - An override for the entry template which adds an extra controls panel that either encourages users to create the app (if they have existing connections using PATs only), or provides a link into GitHub's settings UI (allowing changes to URLs or transferring the app registration to another owner). This also currently includes a stub webhook handler (since GitHub Apps have a single webhook endpoint for all authorized repositories), as well as some commented-out bits for future enhancement. Testing Done: - Connected a GitHub App and installed it into multiple organizations. - Tested all aspects of the wizard flow, including creation of the app and reassignment of any PAT-based repositories after app install. - Verified that API access works correctly when authenticating using the app tokens. - Ran unit tests.	qmxulzkloxrsnquyqwrxwlrrquzplqpr
	Add GitHub App connectivity. This change adds a GitHub App as an alternative to Personal Access Tokens. This involves a bunch of moving parts: 1. The actual GitHub App backend, which includes a redirect view that will trigger the GitHub App Manifest flow, and callback views for when the app has been created and when the app has been installed into a user or organization. This ends up creating a hidden `HostingServiceAccount` which holds the app registration keys, and then each time the app gets installed (for a user or organization) will create a new `HostingServiceAccount` for that entry. 2. Modifications to the GitHub client to use the app for authentication. This involves minting short-lived RS256 JWT tokens for the actual API requests to GitHub. 3. Customized UI parts for the connected services list. This involves: - Special templates and flows for the "Connect a service" wizard which lets users choose how they want to connect, and triggers for the new app creation flow. - An override for the entry template which adds an extra controls panel that either encourages users to create the app (if they have existing connections using PATs only), or provides a link into GitHub's settings UI (allowing changes to URLs or transferring the app registration to another owner). This also currently includes a stub webhook handler (since GitHub Apps have a single webhook endpoint for all authorized repositories), as well as some commented-out bits for future enhancement. Testing Done: - Connected a GitHub App and installed it into multiple organizations. - Tested all aspects of the wizard flow, including creation of the app and reassignment of any PAT-based repositories after app install. - Verified that API access works correctly when authenticating using the app tokens. - Ran unit tests.	qmxulzkloxrsnquyqwrxwlrrquzplqpr

Diff:

Revision 11 (+8280 -44)

Show changes

	reviewboard/admin/views.py
	reviewboard/admin/tests/test_connect_service_view.py
	reviewboard/admin/tests/test_connected_services_list_view.py
	reviewboard/hostingsvcs/github/accounts.py
	reviewboard/hostingsvcs/github/api.py
	reviewboard/hostingsvcs/github/app_auth.py
	reviewboard/hostingsvcs/github/client.py
	reviewboard/hostingsvcs/github/service.py
	13 more

Checks run (2 succeeded)

flake8 passed.

JSHint passed.

Change Summary:

Make use of the newly moved TestCase.login_user instead of reinventing that wheel.

Commits:

	Summary	ID
	Add GitHub App connectivity. This change adds a GitHub App as an alternative to Personal Access Tokens. This involves a bunch of moving parts: 1. The actual GitHub App backend, which includes a redirect view that will trigger the GitHub App Manifest flow, and callback views for when the app has been created and when the app has been installed into a user or organization. This ends up creating a hidden `HostingServiceAccount` which holds the app registration keys, and then each time the app gets installed (for a user or organization) will create a new `HostingServiceAccount` for that entry. 2. Modifications to the GitHub client to use the app for authentication. This involves minting short-lived RS256 JWT tokens for the actual API requests to GitHub. 3. Customized UI parts for the connected services list. This involves: - Special templates and flows for the "Connect a service" wizard which lets users choose how they want to connect, and triggers for the new app creation flow. - An override for the entry template which adds an extra controls panel that either encourages users to create the app (if they have existing connections using PATs only), or provides a link into GitHub's settings UI (allowing changes to URLs or transferring the app registration to another owner). This also currently includes a stub webhook handler (since GitHub Apps have a single webhook endpoint for all authorized repositories), as well as some commented-out bits for future enhancement. Testing Done: - Connected a GitHub App and installed it into multiple organizations. - Tested all aspects of the wizard flow, including creation of the app and reassignment of any PAT-based repositories after app install. - Verified that API access works correctly when authenticating using the app tokens. - Ran unit tests.	qmxulzkloxrsnquyqwrxwlrrquzplqpr
	Add GitHub App connectivity. This change adds a GitHub App as an alternative to Personal Access Tokens. This involves a bunch of moving parts: 1. The actual GitHub App backend, which includes a redirect view that will trigger the GitHub App Manifest flow, and callback views for when the app has been created and when the app has been installed into a user or organization. This ends up creating a hidden `HostingServiceAccount` which holds the app registration keys, and then each time the app gets installed (for a user or organization) will create a new `HostingServiceAccount` for that entry. 2. Modifications to the GitHub client to use the app for authentication. This involves minting short-lived RS256 JWT tokens for the actual API requests to GitHub. 3. Customized UI parts for the connected services list. This involves: - Special templates and flows for the "Connect a service" wizard which lets users choose how they want to connect, and triggers for the new app creation flow. - An override for the entry template which adds an extra controls panel that either encourages users to create the app (if they have existing connections using PATs only), or provides a link into GitHub's settings UI (allowing changes to URLs or transferring the app registration to another owner). This also currently includes a stub webhook handler (since GitHub Apps have a single webhook endpoint for all authorized repositories), as well as some commented-out bits for future enhancement. Testing Done: - Connected a GitHub App and installed it into multiple organizations. - Tested all aspects of the wizard flow, including creation of the app and reassignment of any PAT-based repositories after app install. - Verified that API access works correctly when authenticating using the app tokens. - Ran unit tests.	qmxulzkloxrsnquyqwrxwlrrquzplqpr

Diff:

Revision 12 (+8272 -44)

Show changes

	reviewboard/admin/views.py
	reviewboard/admin/tests/test_connect_service_view.py
	reviewboard/admin/tests/test_connected_services_list_view.py
	reviewboard/hostingsvcs/github/accounts.py
	reviewboard/hostingsvcs/github/api.py
	reviewboard/hostingsvcs/github/app_auth.py
	reviewboard/hostingsvcs/github/client.py
	reviewboard/hostingsvcs/github/service.py
	13 more

Checks run (2 succeeded)

flake8 passed.

JSHint passed.

Change Summary:

Use Pydantic for the app/install records. I think the change was worth it but golly gee.

Commits:

	Summary	ID
	Add GitHub App connectivity. This change adds a GitHub App as an alternative to Personal Access Tokens. This involves a bunch of moving parts: 1. The actual GitHub App backend, which includes a redirect view that will trigger the GitHub App Manifest flow, and callback views for when the app has been created and when the app has been installed into a user or organization. This ends up creating a hidden `HostingServiceAccount` which holds the app registration keys, and then each time the app gets installed (for a user or organization) will create a new `HostingServiceAccount` for that entry. 2. Modifications to the GitHub client to use the app for authentication. This involves minting short-lived RS256 JWT tokens for the actual API requests to GitHub. 3. Customized UI parts for the connected services list. This involves: - Special templates and flows for the "Connect a service" wizard which lets users choose how they want to connect, and triggers for the new app creation flow. - An override for the entry template which adds an extra controls panel that either encourages users to create the app (if they have existing connections using PATs only), or provides a link into GitHub's settings UI (allowing changes to URLs or transferring the app registration to another owner). This also currently includes a stub webhook handler (since GitHub Apps have a single webhook endpoint for all authorized repositories), as well as some commented-out bits for future enhancement. Testing Done: - Connected a GitHub App and installed it into multiple organizations. - Tested all aspects of the wizard flow, including creation of the app and reassignment of any PAT-based repositories after app install. - Verified that API access works correctly when authenticating using the app tokens. - Ran unit tests.	qmxulzkloxrsnquyqwrxwlrrquzplqpr
	Add GitHub App connectivity. This change adds a GitHub App as an alternative to Personal Access Tokens. This involves a bunch of moving parts: 1. The actual GitHub App backend, which includes a redirect view that will trigger the GitHub App Manifest flow, and callback views for when the app has been created and when the app has been installed into a user or organization. This ends up creating a hidden `HostingServiceAccount` which holds the app registration keys, and then each time the app gets installed (for a user or organization) will create a new `HostingServiceAccount` for that entry. 2. Modifications to the GitHub client to use the app for authentication. This involves minting short-lived RS256 JWT tokens for the actual API requests to GitHub. 3. Customized UI parts for the connected services list. This involves: - Special templates and flows for the "Connect a service" wizard which lets users choose how they want to connect, and triggers for the new app creation flow. - An override for the entry template which adds an extra controls panel that either encourages users to create the app (if they have existing connections using PATs only), or provides a link into GitHub's settings UI (allowing changes to URLs or transferring the app registration to another owner). This also currently includes a stub webhook handler (since GitHub Apps have a single webhook endpoint for all authorized repositories), as well as some commented-out bits for future enhancement. Testing Done: - Connected a GitHub App and installed it into multiple organizations. - Tested all aspects of the wizard flow, including creation of the app and reassignment of any PAT-based repositories after app install. - Verified that API access works correctly when authenticating using the app tokens. - Ran unit tests.	qmxulzkloxrsnquyqwrxwlrrquzplqpr

Diff:

Revision 13 (+8974 -68)

Show changes

	reviewboard/admin/views.py
	reviewboard/admin/tests/test_connect_service_view.py
	reviewboard/admin/tests/test_connected_services_list_view.py
	reviewboard/hostingsvcs/github/accounts.py
	reviewboard/hostingsvcs/github/api.py
	reviewboard/hostingsvcs/github/app_auth.py
	reviewboard/hostingsvcs/github/client.py
	reviewboard/hostingsvcs/github/service.py
	15 more

Checks run (2 succeeded)

flake8 passed.

JSHint passed.

The issue has been dropped. Show all issues

Ok so thinking about local sites again (this is on my mind from neglecting to really consider local sites when implementing document review and then having to go in and add it later), is the idea for GitHub app-record accounts to be local-site dependent? This seems to be the current design because we pass local_site for both the app-record accounts and installation accounts (e.g. in make_connect_ui_context() we do HostingServiceAccount.objects.filter(service_name=..., local_site=request.local_site).

But I know you mentioned possibly having a "GitHub App for all of RBCommons" in a reply to one of my other reviews. And we have staff_member_required decorators on the views, which means only server admins (not local site team admins) will be able to access the views.

So even though RBCommons will require its own development effort, I think we need to make some design decisions at this stage since we are currently passing around local sites in this code.

david

July 24, 2026, 10:36 a.m.

Hmm, I'll have to think about that a bit. Will follow up on that in a later change.

reviewboard/hostingsvcs/github/accounts.py (Diff revision 13)
The issue has been resolved. Show all issues
```
Missing a docstring.
```
reviewboard/hostingsvcs/github/accounts.py (Diff revision 13)
The issue has been resolved. Show all issues
```
Could this be Literal['user', 'organization', '']?
```
reviewboard/hostingsvcs/github/accounts.py (Diff revision 13)
The issue has been resolved. Show all issues
```
Same comment as above.
```
reviewboard/hostingsvcs/github/accounts.py (Diff revision 13)
The issue has been resolved. Show all issues
```
Seems like this could be Literal['all', 'selected'].
```
reviewboard/hostingsvcs/github/accounts.py (Diff revision 13)
The issue has been resolved. Show all issues
```
Can you add a docstring for this.
```
reviewboard/hostingsvcs/github/accounts.py (Diff revision 13)
The issue has been resolved. Show all issues
```
This can be removed, we do this below in the if condition.
```

reviewboard/hostingsvcs/github/service.py (Diff revision 13)

The issue has been resolved. Show all issues

We do these isinstance checks on the app data a lot more than we do is_installation_account() or is_app_record_account(). Might be worth making some is_installation_data() is_app_record_data() functions?

reviewboard/hostingsvcs/github/service.py (Diff revision 13)

The issue has been dropped. Show all issues

We can remove local_site here because we do a local_site = app_account.local_site in the view instead of using this value that was passed in.

david

July 24, 2026, 10:36 a.m.

We do that in GitHubAppInstallCallbackView, but this is referring to GitHubAppInstallView.

reviewboard/hostingsvcs/github/service.py (Diff revision 13)
The issue has been dropped. Show all issues
```
Same comment as above.
```

reviewboard/hostingsvcs/tests/github/test_app.py (Diff revision 13)

The issue has been resolved. Show all issues

I'm getting a bit mixed up with the namings. We have "app-record accounts" and "installation accounts". A hosting service account can be either of those.

Can we rename _create_app_record() to _create_app_record_account() to clarify that. And then rename _create_app_account() to _create_app_installation_account() to specify that its an installation account. Because "app account" could really mean either a record account or installation account, you even name the record account variable app_account.

Commits:

	Summary	ID
	Add GitHub App connectivity. This change adds a GitHub App as an alternative to Personal Access Tokens. This involves a bunch of moving parts: 1. The actual GitHub App backend, which includes a redirect view that will trigger the GitHub App Manifest flow, and callback views for when the app has been created and when the app has been installed into a user or organization. This ends up creating a hidden `HostingServiceAccount` which holds the app registration keys, and then each time the app gets installed (for a user or organization) will create a new `HostingServiceAccount` for that entry. 2. Modifications to the GitHub client to use the app for authentication. This involves minting short-lived RS256 JWT tokens for the actual API requests to GitHub. 3. Customized UI parts for the connected services list. This involves: - Special templates and flows for the "Connect a service" wizard which lets users choose how they want to connect, and triggers for the new app creation flow. - An override for the entry template which adds an extra controls panel that either encourages users to create the app (if they have existing connections using PATs only), or provides a link into GitHub's settings UI (allowing changes to URLs or transferring the app registration to another owner). This also currently includes a stub webhook handler (since GitHub Apps have a single webhook endpoint for all authorized repositories), as well as some commented-out bits for future enhancement. Testing Done: - Connected a GitHub App and installed it into multiple organizations. - Tested all aspects of the wizard flow, including creation of the app and reassignment of any PAT-based repositories after app install. - Verified that API access works correctly when authenticating using the app tokens. - Ran unit tests.	qmxulzkloxrsnquyqwrxwlrrquzplqpr
	Add GitHub App connectivity. This change adds a GitHub App as an alternative to Personal Access Tokens. This involves a bunch of moving parts: 1. The actual GitHub App backend, which includes a redirect view that will trigger the GitHub App Manifest flow, and callback views for when the app has been created and when the app has been installed into a user or organization. This ends up creating a hidden `HostingServiceAccount` which holds the app registration keys, and then each time the app gets installed (for a user or organization) will create a new `HostingServiceAccount` for that entry. 2. Modifications to the GitHub client to use the app for authentication. This involves minting short-lived RS256 JWT tokens for the actual API requests to GitHub. 3. Customized UI parts for the connected services list. This involves: - Special templates and flows for the "Connect a service" wizard which lets users choose how they want to connect, and triggers for the new app creation flow. - An override for the entry template which adds an extra controls panel that either encourages users to create the app (if they have existing connections using PATs only), or provides a link into GitHub's settings UI (allowing changes to URLs or transferring the app registration to another owner). This also currently includes a stub webhook handler (since GitHub Apps have a single webhook endpoint for all authorized repositories), as well as some commented-out bits for future enhancement. Testing Done: - Connected a GitHub App and installed it into multiple organizations. - Tested all aspects of the wizard flow, including creation of the app and reassignment of any PAT-based repositories after app install. - Verified that API access works correctly when authenticating using the app tokens. - Ran unit tests.	qmxulzkloxrsnquyqwrxwlrrquzplqpr

Diff:

Revision 14 (+9080 -68)

Show changes

	reviewboard/admin/views.py
	reviewboard/admin/tests/test_connect_service_view.py
	reviewboard/admin/tests/test_connected_services_list_view.py
	reviewboard/hostingsvcs/github/accounts.py
	reviewboard/hostingsvcs/github/api.py
	reviewboard/hostingsvcs/github/app_auth.py
	reviewboard/hostingsvcs/github/client.py
	reviewboard/hostingsvcs/github/service.py
	15 more

Checks run (2 succeeded)

flake8 passed.

JSHint passed.

Change Summary:

Reduce some duplication across test cases.

Commits:

	Summary	ID
	Add GitHub App connectivity. This change adds a GitHub App as an alternative to Personal Access Tokens. This involves a bunch of moving parts: 1. The actual GitHub App backend, which includes a redirect view that will trigger the GitHub App Manifest flow, and callback views for when the app has been created and when the app has been installed into a user or organization. This ends up creating a hidden `HostingServiceAccount` which holds the app registration keys, and then each time the app gets installed (for a user or organization) will create a new `HostingServiceAccount` for that entry. 2. Modifications to the GitHub client to use the app for authentication. This involves minting short-lived RS256 JWT tokens for the actual API requests to GitHub. 3. Customized UI parts for the connected services list. This involves: - Special templates and flows for the "Connect a service" wizard which lets users choose how they want to connect, and triggers for the new app creation flow. - An override for the entry template which adds an extra controls panel that either encourages users to create the app (if they have existing connections using PATs only), or provides a link into GitHub's settings UI (allowing changes to URLs or transferring the app registration to another owner). This also currently includes a stub webhook handler (since GitHub Apps have a single webhook endpoint for all authorized repositories), as well as some commented-out bits for future enhancement. Testing Done: - Connected a GitHub App and installed it into multiple organizations. - Tested all aspects of the wizard flow, including creation of the app and reassignment of any PAT-based repositories after app install. - Verified that API access works correctly when authenticating using the app tokens. - Ran unit tests.	qmxulzkloxrsnquyqwrxwlrrquzplqpr
	Add GitHub App connectivity. This change adds a GitHub App as an alternative to Personal Access Tokens. This involves a bunch of moving parts: 1. The actual GitHub App backend, which includes a redirect view that will trigger the GitHub App Manifest flow, and callback views for when the app has been created and when the app has been installed into a user or organization. This ends up creating a hidden `HostingServiceAccount` which holds the app registration keys, and then each time the app gets installed (for a user or organization) will create a new `HostingServiceAccount` for that entry. 2. Modifications to the GitHub client to use the app for authentication. This involves minting short-lived RS256 JWT tokens for the actual API requests to GitHub. 3. Customized UI parts for the connected services list. This involves: - Special templates and flows for the "Connect a service" wizard which lets users choose how they want to connect, and triggers for the new app creation flow. - An override for the entry template which adds an extra controls panel that either encourages users to create the app (if they have existing connections using PATs only), or provides a link into GitHub's settings UI (allowing changes to URLs or transferring the app registration to another owner). This also currently includes a stub webhook handler (since GitHub Apps have a single webhook endpoint for all authorized repositories), as well as some commented-out bits for future enhancement. Testing Done: - Connected a GitHub App and installed it into multiple organizations. - Tested all aspects of the wizard flow, including creation of the app and reassignment of any PAT-based repositories after app install. - Verified that API access works correctly when authenticating using the app tokens. - Ran unit tests.	qmxulzkloxrsnquyqwrxwlrrquzplqpr

Diff:

Revision 15 (+9096 -68)

Show changes

	reviewboard/admin/views.py
	reviewboard/admin/tests/test_connect_service_view.py
	reviewboard/admin/tests/test_connected_services_list_view.py
	reviewboard/hostingsvcs/github/accounts.py
	reviewboard/hostingsvcs/github/api.py
	reviewboard/hostingsvcs/github/app_auth.py
	reviewboard/hostingsvcs/github/client.py
	reviewboard/hostingsvcs/github/service.py
	15 more

Checks run (2 succeeded)

flake8 passed.

JSHint passed.

Ship it!

reviewboard/hostingsvcs/github/service.py (Diff revisions 13 - 15)
The issue has been resolved. Show all issues
```
This can be an elif or add back in the blank line before this.
```