Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

isEnterprise returns true incorrectly on github.localhost #48

Closed
JasonEtco opened this issue Jun 14, 2022 · 3 comments · Fixed by #51
Closed

isEnterprise returns true incorrectly on github.localhost #48

JasonEtco opened this issue Jun 14, 2022 · 3 comments · Fixed by #51
Assignees

Comments

@JasonEtco
Copy link

JasonEtco commented Jun 14, 2022

Hello! I have an admittedly niche problem - I'm working on a CLI extension against github.localhost, which means setting GH_HOST=github.localhost for each command. Calling isEnterprise returns true in that case, because it is not github.com:

func isEnterprise(host string) bool {
return host != defaultHost
}

That results in an incorrect (and un-fixable) URL here:

func restPrefix(hostname string) string {
if isEnterprise(hostname) {
return fmt.Sprintf("https://%s/api/v3/", hostname)
}
return "https://api.github.com/"
}

As far as I can tell, there's no way for me to say "use GH_HOST, but also use api.<GH_HOST> instead of <GH_HOST>/api/v3". Is that correct, or is there a patch needed here? Happy to open a PR adding an exception for github.localhost if that makes sense, or some more consistent way of setting the full URL?


FWIW, I did think that maybe have GH_HOST=http://api.github.localhost would work, but that gives:

Post "https://http//api.github.localhost/api/v3/repos/:owner/:repo/<REDACTED>"
@mislav
Copy link
Contributor

mislav commented Jun 14, 2022

@JasonEtco Thank you for reporting! This seems to be a bug.

@samcoe What do you think about porting hostname normalization logic over from CLI? https://github.com/cli/cli/blob/4c237708d878008e85e8190d310dc1826b463ca9/internal/ghinstance/host.go#L20-L22

@samcoe
Copy link
Contributor

samcoe commented Jun 14, 2022

@JasonEtco @mislav Yup, we should port over the localhost handling in the hostname normalization logic, it was just an oversite that it isn't already there. It if it isn't super urgent to get this fixed, to avoid conflicts, perhaps we can add it after #44 and #45 land since those PR's change the location of normalization code.

@JasonEtco
Copy link
Author

Ah great, thanks for confirming its a bug y'all! This is not super urgent, I can hack around it locally for now.

@samcoe samcoe self-assigned this Jun 22, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants