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.
These characters get classified as "East Asian Mixed" by Go's
`text/width` package, and thus assumed that their printed version
occupies a width of 2 characters, whereas they each only occupy one.
I'm not sure why they are classified as East Asian, but I did not have
the energy to dive into Go's Unicode tables, so here is a workaround
based on an exclusion list.
When applying metadata to the new PR such as assignees or reviewers, if
the operation fails, an error message would get printed:
failed to create pull request: <API error text>
This was misleading, because the PR did get created; it's just that
updating it failed. The new error message is:
https://github.com/OWNER/REPO/pull/123
pull request update failed: <API error text>
The PR URL is printed on stdout and the error message is printed on
stderr. In case of any errors, the exit code is still non-zero.
* We are trying to keep the binary building on Go 1.13 to support building the project on Ubuntu 20.04 LTS
* Go 1.14+ is required to run the test suite
* We build our releases on Go 1.15
This adds a CI check that verifies that the project compiles on 1.13
If the `--repo` flag is specified, then the user intends to select a
repository other than the current one. In that case, it doesn't make
sense to fall back to detecting the PR belonging to the current branch,
so throw a descriptive error instead.
The "unauthorized_client" error means that OAuth Device Flow is implemented, but either isn't enabled on this GHES instance, or that it isn't enabled for this particular OAuth app. In these cases we fall back to old OAuth app authorization flow.
