Repository navigation
Support for GitHub Enterprise #273
Description
Activity
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.
Reacted by Johannes Plunien, Iain Smith, Matt Hamlin, Sivan Mehta, Thomas Ott, seth, Winston R. Milling, Anders D. Johnson, Tyler Kindy, Jonathan Gilchrist and 24 moreReacted by Johannes Plunien, defel, Adam Jarvis, yyh-gl, Shota Kuwahara, Tomohiro Kusumoto, Peter Grantham, cschaaf, sugitak, Kejml and 5 moreIf 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?
Reacted by Stephen Radachy, Cameron Pascal, Jacob McCann, Josh Hawkins, Brian Martin, drawski and Taylor EdmistonReacted by Pranav Bolar, Brian Martin and Taylor Edmiston@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:
Line 112 in 6685efb
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.
Reacted by Erik Kerber, Geunsik Lim and Max SysoevIt 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 GHEReacted by Cameron Pascal@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 tohttp://localhostWith 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 listworks fine butgh pr statuserrors out with a message about missing fields.Reacted by alex weidner, Josh Hawkins, Aaron Korver and Mislav MarohnićDefinitely would like to see this on GHE 😁
+1 🙏
Reacted by Josh Hawkins and cschaafWould 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!
+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😄Reacted by McLain114, Justin Brodley, martine-stratdat, Jeremy Grant, Ferit Topcu, TUNER88 and Guillaume Xavier TaillonThis is something I'd find very useful (and people I know).
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 tohttp://localhostI 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.comorgithub\.com(regexp), but after pointing them all to (a handful ofconsts) the new values most things did indeed start working.edit: Looks like there are definitely some incompatibilities with that version -
gh pr listworks fine butgh pr statuserrors 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:
CommitPullRequest.16 remaining items
2.15.x
Reacted by arhont3752.19.6
2.19.4
2.18.4
@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! ❤️
Reacted by ajjaskie and Gerard BrullReacted by Adam Luikart, Gerard Brull, Mislav Marohnić, jasmine and TyronSupported Now?
Reacted by Doug ReadingAdding 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 Current
trunkhas 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.
Reacted by Adam Jarvis, Peter Grantham, Adam Luikart and Gibson FahnestockReacted by Adam LuikartI 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/ghto the$PATH, and set up the config by editing~/.config/gh/hosts.yml. There was already agithub.comentry, 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, andpubforkfor things we mirror internally and PR changes to upstream), things don't work. I had hoped that usingGH_REPO=<repo>would allow overriding the automatic detection, but it doesn't seem to be used, and you can't pass full URLs to--repoarguments (#1505).Reacted by Adam Jarvis and Mislav Marohnić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). 🙇Reacted by Jonathan Gilchrist, jasmine, Sebastian Mezger, Yongjin Jung, Aron Cedercrantz, Shu Kutsuzawa, Graham Clark, Thilo Uttendorfer, Gerard Brull and Ryuichi InagakiThis works great, thanks! When should we expect a release with this change?
Is there a separate issue to track forgh pr statussupport?When should we expect a release with this change?
@vtintillier This week!
Is there a separate issue to track for
gh pr statussupport?Yes: #1102
Reacted by Vivien Tintillier, Jonathan Gilchrist and Ricardo Gladwell
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.