Without fixing all ColorScheme.Gray and ColorScheme.Grayf usage in this pull request, golangci-lint throws errors for using deprecated functions.
As that code should be replaced within github/cli#833, I'm removing the deprecation indicator for now to get this PR passing.
This commit covers testing around the new ColorScheme.Muted logic based on various situations to gain confidence we get the accessible colors expected when enabled.
Additionally, this commit includes a small change to the existing 8-bit color logic to standardize on the same reset sequence for testing purposes. Essentially, `ESC[m` and `ESC[0m` are equivalent but this inconsistency with our other libraries makes setting up tests a little extra confusing and difficult.
After discussing this with the team, the `gh config` changes to display `accessible_colors` have been removed from this branch being outside of acceptance criteria. This will be moved to a separate issue along with any other work needed to finalize the public preview such as `gh help` entries for `GH_ACCESSIBLE_COLORS` environment variable.
List commands that use ColorScheme.Gray have been updated to use ColorScheme.Muted.
This commit is focused on incorporating cli/go-gh accessible colors configuration setting into GitHub CLI experience along with new color function to supersede ColorScheme.Gray and ColorScheme.Grayf.
Originally, I was considering having all use of ColorScheme.Gray and ColorScheme.Grayf fallback to the new muted logic if accessible colors were enabled, however I decided not being that it exceeds the acceptance criteria. This means that every command using ColorScheme.Gray needs to be updated to use ColorScheme.Muted
This commit refactors the color format around table headers to ensure the GitHub CLI uses thematically appropriate colors based on dark background, light background, or no color at all.
In order to do so, `ColorScheme` needs information from the terminal about the background appearance (dark, light, none) to determine appropriate muted color.
This commit brings the `gh issue comment` and `gh pr comment` tests in line with one another while also addressing some corner cases that weren't previously tested.
There is still a bit of work to get the gh pr comment tests in order, however this goes a way towards fixing the issue along with acceptance tests.
Also, it turns out some of the issue acceptance tests were really running `pr` tests.
Follow up of https://github.com/cli/cli/pull/7612
The `missingWorkflowScopeRE` is defined to capture
the error message when the `GH_TOKEN` does not have
`workflow` scope in `gh repo sync <remote>`,
but this is only intended for error messages for
OAuth Apps and does not work with GitHub Apps.
In GitHub App, you will get the following error:
```
{
"message": "refusing to allow a GitHub App to create or update workflow `.github/workflows/teamcity-pr-checks.yml` without `workflows` permission",
"documentation_url": "https://docs.github.com/rest/branches/branches#sync-a-fork-branch-with-the-upstream-repository",
"status": "422"
}
```
As you can see above, the existing regexp does not
match the "`workflows` permission".
This change modifies the regexp to return
the user-friendly error message when the `workflow`
permission is missing, even in the case of a GitHub App.
