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.
Before, we implemented the OAuth app authorization flow which requires a
callback URL. To provide such a URL, we had to spin up a local HTTP
server, which was brittle and did not cover cases where a person might
want to authenticate with a browser that runs on a different machine
than the GitHub CLI process.
This implements the OAuth Device Authorization flow where the user is
given a one-time code and asked to paste it in the browser flow. There
is no callback URL, so we can avoid spinning up a local server, and the
user may open a browser on any of their devices, as long as they provide
the correct one-time code.
If the Device Authorization flow is detected to be unavailable for the
OAuth app (right now, it's specifically enabled for GitHub CLI) or for
an older GitHub Enterprise instance, this falls back to the old app
authentication flow.
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 commit hacks the existing repo clone tests into something usable by
the new isolated command. It went ok and was less effort than trying to
introduce the same kind of test format as repo view and gist create.
After a person copies `hosts.yml` to a headless system, they will still
be forced to go through re-authentication flow unless they copy or
initialize a `config.yml` as well. This fixes respecting authentication
info from `hosts.yml` even if `config.yml` is missing.
Read from and write to the `hosts.yml` file every time `config.yml` is
accessed. Everything that before went under the `hosts:` map now belongs
to `hosts.yml`.
We dynamically add hosts on `Set`, so this `hosts` cache might fall out
of date. We could ensure to keep it updated, but I'm not convinced it's
necessary for speed right now.
Previously we would trigger OAuth flow when the config file did not
exist. Now we will let an empty Config object be initialized in that
case, but trigger OAuth flow when the Context caller requests an
AuthToken.
