feat(github): add GitHub App integration

[amCap1712]

Implement GitHub App based authentication as an alternative to personal access tokens for GitHub-backed repositories. The integration stores the app configuration and installation metadata, exchanges app credentials for installation access tokens, and uses those tokens when Weblate performs GitHub repository operations.

Example of a PR opened by the app: https://github.com/amCap1712/weblate-test/pull/2

[amCap1712]

I am working on more testing to ensure that adding the github integration doesn't break existing github pull request or other git integrations.

[nijel]

Does it work for organization-scoped repos as well? (I will look in more detail later, I'm just curious)

[amCap1712]

Yes it should but I have not had the opportunity to test it because of lack of organization access to install it in.

[nijel]

I wonder whether scoping this to the user is the right approach. The user indeed has to initiate this, but shouldn't the connection be bound to a project? Or workspace once #19535 lands?

[amCap1712]

Hmm, good point. I will rework this to project for now and yes workspace seems to make more sense once available.

[nijel]

This should do some scope filtering, in this way, it exposes all site GitHub installations to all users.

[nijel]

This is Codex review of the changes:

• [P1] Validate GitHub remote URLs before probing — /home/nijel/weblate/weblate/weblate/vcs/git.py:2097-2100
  This override dropped the validate_remote_url() call that the base Git implementation performs before git ls-remote. When a user selects the GitHub VCS driver with a URL resolving to a private or otherwise disallowed host, Weblate now runs ls-remote before the outbound/private-
  network checks can reject it, bypassing the existing VCS_RESTRICT_PRIVATE protection; validate repo before _popen.
• [P2] Do not require app signatures for legacy GitHub webhooks — /home/nijel/weblate/weblate/weblate/trans/views/hooks.py:562-563
  This fallback assigns the single configured GitHub App host even to ordinary push webhooks that have no installation payload. _authenticate_github_app_webhook() then enforces the app webhook secret, so existing repository webhooks start returning 403 unless they were also
  configured with the App secret; only app deliveries, or deliveries whose signature actually identifies a host, should be forced through that check.
• [P2] Use the GitHub Enterprise app install path — /home/nijel/weblate/weblate/weblate/vcs/github.py:109-110
  For hosts other than github.com, GitHub Enterprise Server exposes GitHub App installation pages under /github-apps//..., not /apps//.... With the current URL, the documented Enterprise host flow sends users to a non-existent install page, so the prefix needs to be
  conditional on the configured hostname.

[nijel]

Thinking more about this, I don't think the app should use the same webhook endpoint as generic GitHub hooks. The app hooks should always require signing and should do no fuzzy matching on the repositories, as the repository URL is configured via the app.

[amCap1712]

Makes sense, will update.

Have you been able to test this manually yet? I can deploy a version locally and expose it online for you to access and test if not.

[nijel]

I will get to it soon. First, I want to land basic workspaces code to main.

[nijel]

Just tried this:

• The app creation is non-obvious (what should be Callback URL, is there some expected Setup URL, what permissions and event subscriptions are needed), so the documentation really needs to cover this
• Because of not setting the some of the URLs (probably) the workflow is not smooth - you choose repositories to access and end up on the GitHub app settings page rather than going back to Weblate to continue with the import
• The "Import" button doesn't preserve the project passed to the create page
• Should we allow editing of the repository URLs when configured via GitHub app? That could potentially leak the credentials to other services and will most likely break the integration. Perhaps using separate VCS backend which will restrict these changes would be better.
• It worked just fine for organization scoped repo (Translations update from Weblate github-app-testing#1)

[amCap1712]

1. I documented some things but yeah it seems I forgot to add that. Will fix.
2. Not sure what you mean by this one, can you share a screen recording maybe where it breaks?
3. Will fix.
4. A separate backend would definitely simplify things, will do.
5. I see workspaces is now merged so I'll rework this to connect to that instead of project.

[nijel]

2 is IMHO caused by not setting callback/setup URLs on GitHub. After selecting where to install the GitHub app, I ended up on https://github.com/settings/installations/135697804 rather than in Weblate where I would choose which repo to import.

Yes, the basics of workspaces are now there, but I have several follow-up pull requests prepared so that it doesn't all land in one massive change (#19729 is the current next step).

[nijel]

While working on the workspaces, I this we can make the GitHub app work only with workspaces and do not support project-scoped installs at all. This will simplify the code and the limitation should not be that constraining, it just needs to be documented.

[codecov]

⚠️ JUnit XML file not found

The CLI was unable to find any JUnit XML files to upload.
For more help, visit our troubleshooting guide.

[amCap1712]

I have added an option to register an application automatically. Currently the downside is that the credentials are stored in the database but we can change it to showing the credentials to the user on the website and having them manually update settings.py. What do you think?

I was trying to generate some tests with codex but I don't think they are upto the mark yet so I will iterate on them manually. Let me know if you think any other major changes are needed for the integration before I proceed with that.

[nijel]

The registration looks nice and makes it harder to mess up the setup. Storing the credentials in the database is IMHO okay.

I'm still unsure about the hooks code, I don't think we should do that much of guessing there. How about exposing hook per integration (let's say /hooks/integrations/<ID>/) and that would be configured in the GitHub app and verify only it's secret. Eventually we want to phase out unauthenticated hooks and this would eventually allow us to use authentication even for manual hooks (given they will get the integration).

Overall while this PR is GitHub specific, it should be prepared for a generalization later.

For integration/webhooks, we would like to support other code sites such as GitLab or Forgejo. So the model should be prepared for that. Enabling authenticated webhooks (via the integration) should disable unauthenticated hooks on that component.

For VCS integration:

• the site admin would configure the integrations.
• the workspace admin can connect it to the code hosting organization (or individual account)
• the component creation would then default to selection of repos exposed by the integration

This is not the scope we need to cover in this pull request, but the GitHub integration should go in the right direction.