Whenever a SSO challenge gets issued by the server by means of a URL in
the `X-GitHub-SSO` response header, gh now additionally prints that URL
on the standard error stream.
This is achieved by installing a middleware to all HTTP requests and
storing the server challenge to a value accessible by `factory.SSOURL()`.
Such approach was made necessary mainly because of the
`shurcool-graphql` client which doesn't give access to response headers
when a GraphQL error case is encountered.
This is to avoid hitting the filesystem and resolving symlinks
unnecessarily. The value of executable is just used conditionally by a
handful of commands.
Before:
$ GH_ENTERPRISE_TOKEN="..." gh pr create
could not find hosts config: not found
Now:
$ GH_ENTERPRISE_TOKEN="..." gh pr create
set the GH_HOST environment variable to specify which GitHub host to use
Also amends `gh help environment` documentation to suggest the use of
GH_HOST when scripting operations with GitHub Enterprise repositories.
- Extensions on Windows now enabled through the `sh.exe` interpreter
- `sh.exe` now found on Windows when git was installed via scoop
- `gh extensions list` command shows origin repo for the extension
- `gh extensions upgrade --all` is required to upgrade all extensions
- Added `gh extensions remove`
- Shell completions now include aliases and extension names
- `gh` help output now lists available extension names
- Extensions are stored to XDG_DATA_HOME
If these tests are going to exerise `factory.New()`, the config getter
should always be overriden since the default config getter reads from
`~/.config/gh` and thus makes tests dependent on the user's environment.
This removes sensitivity to the BROWSER environment variable in tests
and makes it easier to verify the URL that the browser was invoked with
without having to stub sub-processes.
This keeps git operations working even when PATH is modified, e.g. `brew
update` will work even though Homebrew runs the command explicitly
without `/usr/local/bin` in PATH.
Additionally, this inserts a blank value for `credential.*.helper` to
instruct git to ignore previously configured credential helpers, i.e.
those that might have been set up in system configuration files. We do
this because otherwise, git will store the credential obtained from gh
in every other credential helper in the chain, which we want to avoid.
Before:
git config --global credential.https://github.com.helper '!gh auth git-credential'
After:
git config --global credential.https://github.com.helper ''
git config --global --add credential.https://github.com.helper '!/path/to/gh auth git-credential'
* Respect system/user timezone in API requests
* Fall back to a known timezone if TZ is not set
Co-authored-by: Cristian Dominguez <cristiand391@users.noreply.github.com>
Adding GITHUB_TOKEN & GITHUB_ENTERPRISE_TOKEN support orthogonal to
Config was getting out of hand, especially in `auth` commands that
adjust their messaging and error status based on the presence of these
environment variables.
The new approach builds in support for tokens from environment straight
into Config object by composition. Thus, commands need not ever be
concerned with any specific environment variables.
Due to our HTTP client default behavior, an `Accept` header is added to
all API requests. This is fine for all commands except `gh api`, where
the user should ideally have fine-grained control over most aspects of
HTTP requests and where there should be little to no defaults in general.
