Allow explicitly setting hostname for gh operations #1517
Conversation
Accept the "HOST/OWNER/REPO" syntax or passing a full URL for both the
`--repo` flag and the GH_REPO environment variable and allow setting
GH_HOST environment variable to override just the hostname for
operations that assume "github.com" by default.
Examples:
$ gh repo clone example.org/owner/repo
$ GH_HOST=example.org gh repo clone repo
$ GH_HOST=example.org gh api user
$ GH_HOST=example.org gh gist create myfile.txt
$ gh issue list -R example.org/owner/repo
$ gh issue list -R https://example.org/owner/repo.git
$ GH_REPO=example.org/owner/repo gh issue list
This ensures that while having git remotes to point to either `github.com` or authenticated GHE instances, adding another git remote pointing to an unrelated host won't change the remote resolution in any way, even if the unrelated remote is called `upstream` or `github` (and thus normally took precedence).
| func (rr *remoteResolver) Resolver() func() (context.Remotes, error) { | ||
| var cachedRemotes context.Remotes | ||
| var remotesError error | ||
|
|
||
| return func() (context.Remotes, error) { |
There was a problem hiding this comment.
The caching here feels premature. Unless I'm missing something the costliest action here is reading remotes on disk and unless we've benchmarked that as human-noticeable I'd rather get rid of the complexity of this closure-based approach and not worry about caching remotes.
There was a problem hiding this comment.
It might be, and you're right that I just guessed that this might be slow.
This logic includes shelling out to a subprocess (git remote -v) and parsing that and ~/.ssh/config if it exists. Now that I've actually measured it on my machine (high-end MBP), it usually takes 6-10ms. However, it does get called at least twice for some commands, and I have a hunch some code paths around pr create and pr checkout that consult remotes a lot might call it even more than twice. That puts the combined cost of the lookup in the 20–40ms range, which I think starts being noticeable by humans. However, in most cases this caching only shaves off up to 10ms, so you might be right that the caching is premature.
What are your thoughts now that we know the numbers?
There was a problem hiding this comment.
I was envisioning that this would only be called 1-2 times per command; but good point that it could be a number of times for pr create. It sounds like this can creep into the human-noticeable range so let's keep it for now; it's easy enough to take out later.
| // TODO: GHE support | ||
| gist, err := apiCreate(httpClient, ghinstance.Default(), opts.Description, opts.Public, files) | ||
| gist, err := apiCreate(httpClient, ghinstance.OverridableDefault(), opts.Description, opts.Public, files) |
There was a problem hiding this comment.
To mark this TODO as done is the missing piece the ability to post gists to a GHE host without needing GH_HOST?
There was a problem hiding this comment.
Do you feel that commands such as api and gist create should also accept a --host parameter, so that all necessary parameters can be passed via arguments?
There was a problem hiding this comment.
Not urgently; it's something I'm comfortable waiting for a user to request. My current hunch is that people will mostly use github.com or their enterprise host and that we don't need flags like that. I was just curious about the TODO.
There was a problem hiding this comment.
You're right; I think I just forgot to take that TODO comment out. But I'm also wondering whether there should be a --host flag for these commands. I'm also comfortable waiting and seeing the community reaction.
For people who mostly just use their GHE and not github.com, we were also considering a configuration option such as default_host to select a default hostname as an alternative to GH_HOST environment variable. But this feels like it would be better as a follow-up changeset.
correct: |
This adds the missing bit of GitHub Enterprise support in which users can select a hostname to perform the operation against when that hostname cannot be inferred from an existing git repository.
-R, --repoflag to override the repository for issue/PR operations now accepts theHOST/OWNER/REPOformat, as well as full URLs;--repoflag does;github.com. This affects operations such asgh api,gh gist create,gh repo clone myrepo, etc.Examples:
Fixes #1180, fixes #1505, closes #273