Support GitHub Enterprise for the Pull Requests feature#5596
Conversation
brianphillips
left a comment
brianphillips
left a comment
There was a problem hiding this comment.
@stefanhaller confirmed that this works with our internal GitHub Enterprise Server instance. Thanks!
@brianphillips Thanks for testing. Do you also have github.com repos, and does switching between those and the enterprise ones work seemlessly too? |
|
@stefanhaller I'm not sure exactly what you mean by switching between github.com and enterprise. Do you mean having a fork of a github.com repo on our internal GHE instance with PR branches with upstream branches on both remotes? Or something entirely different? |
|
@brianphillips I'm not sure either what I mean :). I'm so unfamiliar with using gh for anything other than github.com that maybe it's a stupid question. Do I understand it right that you can login to both gihub.com (using |
|
@stefanhaller then yes, it works 🙂 I have tested it on both types of repositories and it seamlessly picks up the necessary authentication from |
…rvice
The github pull-request fetcher needs to know whether a given remote is a
github-type service, which host its API lives on, and which owner/repo to
query against. Today the fetcher hardcodes the first two ("does the URL
contain github.com" and "https://api.github.com/graphql") and re-derives
owner/repo from the remote, which precludes GitHub Enterprise and makes
the fetch entry point take more arguments than it needs.
Add an accessor on the hosting service manager that exposes the already-
resolved service domain together with the parsed owner/repo, so callers
can answer all of these questions without reaching into the manager's
internals.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The branches-panel PR icons only worked for github.com remotes. There was no
fundamental reason — the auth library we already vendor (cli/go-gh) supports
enterprise tokens out of the box (GH_ENTERPRISE_TOKEN, gh auth's keyring),
and the user-facing 'services' config has long been the documented way to
tell lazygit "this domain is a github service" for the View-PR-URL feature.
The fetcher just hardcoded github.com in three places:
- a substring check on the remote URL to decide we're "in a github repo",
- the GraphQL endpoint (always api.github.com/graphql), and
- the auth lookup (always against the default host).
Plumb the resolved web domain through instead. Detection now goes through
the hosting_service ("is this remote's provider 'github'?"), which means a
user with services: { 'git.acme.com': 'github:git.acme.com' } configured
gets PR icons on their GHE remotes too.
Replacing the substring check with a provider check also tightens a latent
bug in getGithubRemotes: it previously accepted any remote whose URL parsed
with the default regex, including gitlab and bitbucket — masked today only
by the InGithubRepo gate, but exposed once the gate goes away.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Doing this in a separate commit makes the previous commit's diff easier to read.
The services config has been the path for GHE for a while (for the View-PR-URL feature) but it now does double duty: it's also what enables the branches-panel PR icons for non-github.com hosts. Worth calling out explicitly so users don't assume it's still github.com-only. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Compile them only once at startup. I didn't measure if this makes a difference, but it's easy to do, and now that we potentially need to check them more often, it might be worth it.
stefanhaller
force-pushed
the
github-enterprise
branch
from
fbcd545 to
692f56a
Compare
2 participants
The feature to show PR icons in the branches list only worked for github.com, but not for GitHub Enterprise remotes. This PR makes that work, if you configure a services entry for it as explained here.
Prior art: #5559.