feat: Add support for GHE / Data Residency#480
Conversation
…jects#479) Make all GitHub host references configurable via environment variables so the app can run against GHE.com Data Residency tenants (*.ghe.com) and GitHub Enterprise Server, in addition to github.com. - New helpers in src/utils/github-urls.ts derive server/API/OAuth URLs from GITHUB_SERVER_URL (with smart derivation: github.com -> api.github.com, *.ghe.com -> api.<tenant>.ghe.com, anything else -> <server>/api/v3). GITHUB_API_URL overrides derivation. - Octokit (bot/rest.ts) and Probot (pages/api/webhooks.ts) are configured with the derived baseUrl. createAppAuth requests also use the configured base URL via @octokit/request defaults. - NextAuth GitHub provider routes authorization/token/userinfo through the configured GHE host and uses a custom userinfo.request to fetch /user/emails from the configured API host (next-auth v4 hardcodes api.github.com otherwise). OAuth refresh URL uses env. - generateAuthUrl builds git remotes from GITHUB_SERVER_URL host. - Committer email domain is configurable via GITHUB_USER_EMAIL_DOMAIN (default users.noreply.github.com preserves current behavior). - UI components use getGitHubServerUrl() for fork/org links; client bundles read NEXT_PUBLIC_GITHUB_SERVER_URL / NEXT_PUBLIC_GITHUB_API_URL inlined at build time. - webhook-relay.mjs script wires baseUrl into octokit.App and warns when not targeting github.com (polling endpoint is best-effort on GHE). - .env.example and docs (README.md, docs/developing.md) document the GHE.com / GHES configuration and Docker build-arg requirement. - Added tests for URL derivation covering github.com defaults, GHE.com Data Residency, GHES, and explicit overrides. Defaults are unchanged, so existing github.com / GHEC deployments continue to work without any new configuration. Closes github-community-projects#479 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…-support feat: add GHE.com Data Residency / GHES support (github-community-projects#479)
fix: correct GHES URL wiring and Docker client build args
mbianchidev
changed the title
|
@wrslatz it should be ready for review 👍 |
riley-kohler
left a comment
riley-kohler
left a comment
There was a problem hiding this comment.
Apologies for the delay in review. I think we should lean on users setting all of the custom environment variables if necessary instead of attempting to derive values from those that are passed in. There is a lot of logic here that is hard to verify and will be hard to maintain in case GitHub changes URL structure or adds a new type of environment in the future. If there are GitHub provided functions that do this sort of thing we could lean on those but barring that I think that envs will be much easier to implement, test, and maintain.
| githubGraphQlEndpointPlugin, | ||
| ).defaults({ baseUrl }) | ||
|
|
||
| export const probot = createProbot({ defaults: { Octokit: GheProbotOctokit } }) |
There was a problem hiding this comment.
This export isn't referenced anywhere and can be removed
There was a problem hiding this comment.
Maybe I'm missing something but I think with these new settings we need GheProbotOctokit to be injecting the confs?
Aside from that, is there anything else that would need changes? Thanks a lot for reviewing!
There was a problem hiding this comment.
Yeah, it wasn't introduced in your change but that export was always extraneous and the createProbot below is what is actually used.
Generally, I think the github-urls and commiter-email file as well as any other helpers should be removed in favor of just using the environment variables where they are needed. Setting a default value can likely be done in env.mjs so that "?? https://api.github.com" or the like isn't necessary. Ideally the NEXT_PUBLIC variables are removed in favor of one clean env for each value but I understand that the envs aren't available by default from the UI in next so they might need to be exposed through a function.
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> Signed-off-by: Matteo Bianchi <37507190+mbianchidev@users.noreply.github.com>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> Signed-off-by: Matteo Bianchi <37507190+mbianchidev@users.noreply.github.com>
…xport refactor: remove derive GitHub URL functionality in favor of explicit setup
This pull request adds comprehensive support for GitHub Enterprise Cloud with Data Residency (
*.ghe.com) and GitHub Enterprise Server (GHES) deployments that do not use GitHub connect.It introduces new environment variables for configuring GitHub server and API URLs, ensures these variables are available both server- and client-side, and updates the codebase to use these variables throughout authentication, API requests, UI links, and webhook relays. Documentation is also updated to guide users on configuring and building the app for GHE.com and GHES.
Enterprise GitHub configuration support:
GITHUB_SERVER_URL,GITHUB_API_URL,NEXT_PUBLIC_GITHUB_SERVER_URL,NEXT_PUBLIC_GITHUB_API_URL,GITHUB_USER_EMAIL_DOMAIN) in.env.exampleand documented their usage for GHE.com and GHES inREADME.mdanddocs/developing.md.env.mjsto support the new variables, ensuring they are available both server- and client-side.Authentication and API integration:
nextauth-options.tsto use the configured GitHub server/API URLs for OAuth endpoints and user info, overriding defaults to support GHE.com/GHES.UI and UX improvements:
github.comlinks in UI components with dynamic links based on the configured GitHub server URL, ensuring correct navigation for all deployments.These changes make the app robust and configurable for both public GitHub and enterprise GitHub deployments, improving flexibility and user experience across different hosting scenarios.