* Add --maintainer-edit flag
Closes#2213 while retaining backwards compatibility.
* Fix linting
* Adjust documentation and validation
* Negate logic and fix build errors
* rename to no-maintainer-edit
* test
* use a positive option instead of negative
Co-authored-by: vilmibm <vilmibm@github.com>
* 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>
Old message:
read-only token in GH_TOKEN cannot be modified
This message was vague and some users did not understand that this
refers to the value that is read from environment variables.
New message:
$ GH_TOKEN=123 ghd auth login -h github.com
The value of the GH_TOKEN environment variable is being used for authentication.
To have GitHub CLI store credentials instead, first clear the value from the environment.
When gh was built from source, the version number will look something
like this since it's taken from `git describe`:
v1.4.0-34-g{SHA}
When compared as semver against `v1.4.0`, the latter version is falsely
reported as newer. This is because the output of `git describe` wasn't
meant to be interpreted as semver.
The solution is to translate the `git describe` string to faux-semver so
it can be safely compared with the version reported from the server.
Fixes this case:
A new release of gh is available: v1.4.0-41-g2f9e4cb1 → v1.4.0
https://github.com/cli/cli/releases/tag/v1.4.0
For asserting command output, exact string matches are preferred in most cases. In cases when a pattern match is needed, the test can use regexp ad hoc.
For operations such as closing an issue or merging a PR, we would
display the success icon (a checkmark) in red and magenta colors,
respectively, to reflect the latest state of the record operated on
(red: closed; magenta: merged).
This was always confusing to me, seeing it both in code and in the UI,
because I'm instinctively thinking that it's a bug and have to remind
myself that it's by design.
From February 2021, in order to provide feedback on pull requests, Code Scanning workflows must be configured with both `push` and `pull_request` triggers. This is because Code Scanning compares the results from a pull request against the results for the base branch to tell you only what has changed between the two.
Early in the beta period we supported displaying results on pull requests for workflows with only `push` triggers, but have discontinued support as this proved to be less robust.
See https://docs.github.com/en/free-pro-team@latest/github/finding-security-vulnerabilities-and-errors-in-your-code/configuring-code-scanning#scanning-pull-requests for more information on how best to configure your Code Scanning workflows.
