Add support for supplying a port name for a GitHub host

[mntlty]

Ran into a small papercut with GH_HOST env var

When adding a port to the host, for example github.localhost:xxx, the CLI does not correctly identify it as a local instance as in https://github.com/cli/cli/blob/ba27e5bfb88bab29021ae0eace03348e41f0b24f/internal/ghinstance/host.go#L60 and https://github.com/cli/cli/blob/ba27e5bfb88bab29021ae0eace03348e41f0b24f/internal/ghinstance/host.go#L73 we look for equality which doesn’t match if the user includes the port. The result is an incorrect path for the api and protocol (https instead of http).

This can be fixed by either

• remapping the server port to 80, which may not always be possible
• not including the port in the GH_HOST env var

It’s not a blocker but it was surprising behavior which took me a few minutes to understand and unblock myself.

As a follow up thought, I wonder if it's worth handling the IP for localhost 127.0.0.1 as well.

Describe the bug

A clear and concise description of what the bug is. Include version by typing gh --version.

Steps to reproduce the behavior

As an example:

GH_HOST="github.localhost:56530" gh api graphql -F query='
query viewer {
        viewer{
                        id
                }
        }
'

will make a Post "https://github.localhost:56530/api/graphql" request.

Expected vs actual behavior

With a GH_HOST for localhost the API path should be match https://github.com/cli/cli/blob/ba27e5bfb88bab29021ae0eace03348e41f0b24f/internal/ghinstance/host.go#L61

[mislav]

I think this could be solved by adding support throughout the gh codebase for the following environment variables that would supersede GH_HOST:

• GITHUB_API_URL, with the default being https://api.github.com,
• GITHUB_GRAPHQL_URL, with the default being https://api.github.com/graphql,
• GITHUB_SERVER_URL, with the default being https://github.com.

I didn't invent these names: they are automatically set in GitHub Actions and Codespaces environments. They are already respected by our gh codespace API client, but not elsewhere in gh.

The benefit of supplying full URLs would be:

• Ability to specify the port number. GH_HOST does not support this since it's only a host name;
• Ability to specify scheme. We currently default to https for most GitHub hosts and http for "local" ones;
• Ability to specify the REST prefix and GraphQL endpoint separately from the web hostname. Right now we assume https://api.<HOST> for github.com/github.localhost and https://<HOST>/api for others, but inferring the API prefix from the host name isn't always accurate, and ideally the user should be able to configure this explicitly, which would mostly aid in testing.

Here are the current places that do magic with hostnames and that would need to get expanded with GITHUB_*_URL support:

• GH_HOST https://github.com/cli/go-gh/blob/32d3260f8cc2b282a3751d278f1b18f9e0695477/pkg/auth/auth.go#L134
• REST API prefix
  • https://github.com/cli/go-gh/blob/32d3260f8cc2b282a3751d278f1b18f9e0695477/internal/api/rest_client.go#L119-L131
  • https://github.com/cli/cli/blob/3b2397811400a6bc5d98f9e66cd95d34c377bb0e/internal/ghinstance/host.go#L66-L77
• GraphQL API endpoint
  • https://github.com/cli/go-gh/blob/32d3260f8cc2b282a3751d278f1b18f9e0695477/internal/api/gql_client.go#L113-L125
  • https://github.com/cli/cli/blob/3b2397811400a6bc5d98f9e66cd95d34c377bb0e/internal/ghinstance/host.go#L53-L64
• server prefix https://github.com/cli/cli/blob/3b2397811400a6bc5d98f9e66cd95d34c377bb0e/internal/ghinstance/host.go#L102-L107

Ref. https://github.com/cli/cli/issues/7081

[TSenter]

I'm not sure how urgent this is, but I would like to second this. My organization hosts GHES over HTTP, not HTTPS, so I cannot currently use the CLI. Either I can include the protocol with the host, which is rejected, or I exclude it, which defaults to HTTPS and is rejected, since the server is only available via HTTP.

For clarification, our instance is not publicly accessible, and we use SSH for Git operations, the instance just doesn't run over HTTP.

[williammartin]

One thing that concerns me from Mislav's suggestion above is that if these env vars are already in actions, and we begin respecting them as superseding, it would be a breaking change to anyone setting GH_HOST to target some other environment. Consider for example, a project that copies issues between github.com and a GHES. I'm not sure how to find the data on that.

Am I misunderstanding something?

[MikeJansen]

Adding the ability to specify ports is very helpful. Our specific use case is GitHub enterprise in an AWS account accessed via SSM port forwarding. Current security restrictions prevent us from accessing the server via a VPN or ingress.

[williammartin]

Ooh that's very nice to hear about your use case (so far they've all been development related). Thanks!