Support for GitHub Enterprise

This looks awesome! Are you planning GHE support already?

Update from the GitHub CLI team:

In the README we shared additional information about this to help set expectations. Enterprise Server support is something we're really excited to provide, but we want to ensure it's actually usable and that the API endpoints are available on the GHES versions people are using.

GHES support is desired, but we didn't initially prioritize it since our UI relies on the GraphQL API which is only present in the most recent releases of GHES. We wanted to focus on adding features and polish until the GraphQL API became more prevalent among GHES installs before taking the time to add compatibility.

That said, we didn't have an issue capturing this desire so I'll leave this open as the first step.

If we have a GraphQL-supporting version of GHE, do you imagine it would be difficult to fork this repo and shim in our GHE URLs?

@eskerber

If we have a GraphQL-supporting version of GHE, do you imagine it would be difficult to fork this repo and shim in our GHE URLs?

A quick glance of the code suggests you can set the GHE url here:

cli/api/client.go

Line 112 in 6685efb

url := "https://api.github.com/graphql"

I didn't see anywhere else in the codebase where the API url is set, although I did not look particularly hard.

There is also probably something that needs to be done to point the oauth flow at GHE.

It is also hardcoded in multiple files in context/. I was able to update all of those occurrences and build the tool locally, but got a 404 for the authorizer callback, I am supposing because the GitHub app "GitHub CLI (dev)" does not exist on my instance of GHE

@booninite You can solve that by creating your own OAuth app and changing the client ID and client secret which are hardcoded in context/config_setup.go.

~~The CLI also listens on a different port during each auth request so you'll need to modify the callback URL in your OAuth app to match the port for the current auth attempt.~~ You also need to set the callback URL to http://localhost

With the URLs changed, the OAuth app created and the callback URL set correctly, I was able to get this working against the Github Enterprise instance I'm using.

edit: Looks like there are definitely some incompatibilities with that version - gh pr list works fine but gh pr status errors out with a message about missing fields.

Definitely would like to see this on GHE 😁

+1 🙏

Would be great if it works with GHE.

+1 GHE support would make this super powerful.
It would also be great to see support for GHE site admin operations, but I understand that core features are the priority at the moment.

+1 Our engineers would love this for use with our internal GHE instance!

@vilmibm

Hi @vilmibm, thanks for the update. Is it possible to have this as a configuration? Could be used as an experiment for GHE

+1. Supporting Enterprise editions would be really useful! As a user, my preferred way of using this tool for normal as well as enterprise GitHub might be to have a configuration setting of GitHub domain in a config file for gh 😄

This is something I'd find very useful (and people I know).

@jgilchrist

From @jgilchrist:

~~The CLI also listens on a different port during each auth request so you'll need to modify the callback URL in your OAuth app to match the port for the current auth attempt.~~ You also need to set the callback URL to http://localhost

I also had to hardcode the port in the OAuth client; probably magic on GitHub's side, or am I missing something?

With the URLs changed, the OAuth app created and the callback URL set correctly, I was able to get this working against the Github Enterprise instance I'm using.

It took me substantially more to get things working. There are a lot of magic references to github.com or github\.com(regexp), but after pointing them all to (a handful of consts) the new values most things did indeed start working.

edit: Looks like there are definitely some incompatibilities with that version - gh pr list works fine but gh pr status errors out with a message about missing fields.

Based on #286, it seems like this is more GitHub magic, since this is the failure mode for PATs (read: other OAuth ClientIDs). Plus, those symbols do not event show up in the public API: Commit PullRequest.

2.15.x

2.19.6

2.19.4

2.18.4

@okuryu

@okuryu's idea was a lot better than mine! 😅 If you don't mind reacting on their message above that would be wonderful. Sorry for the incredibly noisy way I initially chose to ask for this feedback, and thanks so much to everyone who has responded! ❤️

Supported Now?

Adding support for GHE but saying "only works on GHE 2.20+" (or whatever the needed minimum version is) would be really nice, and then supporting older GHEs could be a follow-on enhancement if needed.

If I knew what the minimum version of GHE that would work was, I could go pester our GitHub Enterprise admins to upgrade 😁 .

Seeing as it was removed from the To do list, does this mean it's now usable with GHE? I don't see any specific instructions on how to set it up.

@Jarvvski

@Jarvvski Current trunk has support for running commands within repositories cloned from a GHE instance, but there are still rough edges around general GHE support (mostly it lacks polish around authentication flow) and we don't recommend experimenting with it until we cut the next release. We will be sure to update this thread and provide some instructions how to get started. 🌟

Seeing as it was removed from the To do list

We removed this card, but we still keep other, more specific GHE-related cards in that project. It's one of our main focuses for this month.

@mislav

Cheers @mislav

I know you said not to play with it, but I had a try anyway 😅 . I followed the build from source instructions, added the resulting bin/gh to the $PATH, and set up the config by editing ~/.config/gh/hosts.yml. There was already a github.com entry, so I just added an entry for my GHE URL, and reused my hub config token (from ~/.config/hub):

github.com:
    user: gibfahn
    oauth_token: <existing github token>
<ghe url>:
    user: <ghe username>
    oauth_token: <ghe oauth token>

Nicely, whenever something fails, you get an error telling you what permissions to add to your oauth token:

$ gh co 1
GraphQL error: Your token has not been granted the required scopes to execute this query. The 'name' field requires one of the following scopes: ['read:org', 'read:discussion'], but your token has only been granted the: ['read:user', 'repo', 'user:email'] scopes. Please modify your token's scopes at: https://<ghe url>/settings/tokens.

Things seem to work pretty well when you only have remotes from one of GHE or github.com. When you have remotes in both though (e.g. I have up, fork, pub, and pubfork for things we mirror internally and PR changes to upstream), things don't work. I had hoped that using GH_REPO=<repo> would allow overriding the automatic detection, but it doesn't seem to be used, and you can't pass full URLs to --repo arguments (#1505).

Thanks for your patience, everyone! The next release of gh will include support for GitHub Enterprise. While the last bits of implementation are still in review, you can try it out from this branch: #1517

To get started, assuming your Enterprise instance lives on example.org:

make
bin/gh auth login -h example.org
bin/gh repo clone example.org/<owner>/<repo>

So far, I have only tested with GHE 2.20, but I suspect that most operations (other than gh pr status) should work even on versions as far back as 2.18. If you do end up trying this out and get unexpected errors, please report the operation you've tried, the error, and your GHE version to either the PR above, or to a separate issue (e.g. if the PR has been merged in the meantime). 🙇

This works great, thanks! When should we expect a release with this change?
Is there a separate issue to track for gh pr status support?

@vtintillier

When should we expect a release with this change?

@vtintillier This week!

Is there a separate issue to track for gh pr status support?

Yes: #1102

Navigation Menu

Repository navigation

Support for GitHub Enterprise #273

Update from the GitHub CLI team:

16 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Support for GitHub Enterprise #273

Description

Update from the GitHub CLI team:

Activity

vilmibm commented on Jan 29, 2020

erikkerber commented on Feb 12, 2020

cameron-pascal commented on Feb 12, 2020

shimmerjs commented on Feb 12, 2020

jgilchrist commented on Feb 12, 2020

Jarvvski commented on Feb 12, 2020

remy-bardou-lifeonair commented on Feb 13, 2020

jduan commented on Feb 13, 2020

joebyneil commented on Feb 13, 2020

simonwalton commented on Feb 13, 2020

pmarques commented on Feb 13, 2020

athityakumar commented on Feb 13, 2020

martine-stratdat commented on Feb 14, 2020

carnott-snap commented on Feb 14, 2020

16 remaining items

rgladwell commented on Apr 7, 2020

uolot commented on Apr 7, 2020

idlem1nd commented on Apr 7, 2020

poteirard commented on Apr 7, 2020

billygriffin commented on Apr 7, 2020

SebastianLavertheDe commented on May 20, 2020

gibfahn commented on Aug 5, 2020

Jarvvski commented on Aug 6, 2020

mislav commented on Aug 6, 2020

Jarvvski commented on Aug 6, 2020

gibfahn commented on Aug 8, 2020

mislav commented on Aug 12, 2020

vtintillier commented on Aug 24, 2020

mislav commented on Aug 25, 2020

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions