Outside of the hostnames previously fixed, I talked with @williammartin about what to do with the remaining references and the concern about the mixed format.
One suggestion for the error / test use case was to remove the extraneous text all together.
This commit changes <github.com> and <ghe.com> references to `github.com` and `ghe.com` so they are visible on the GitHub CLI marketing website.
GitHub Pages will render URLs with a protocol as clickable links, however hostnames are treated as HTML elements and not rendered.
This commit converts all of the places using ColorScheme.Gray and ColorScheme.Grayf to Muted and Mutedf.
There is a little extra tidying up with local variable names or converting code to use Mutedf format.
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.
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.
`gh repo rename` can only rename a repo, but not change its owner
(i.e. transfer it).
As flagged in #10034, at the moment, the CLI behaves like it can do
this, and produces weird results.
If I ask to rename my repo to `polyseam/frappe-containers`:
```bash
gh repo rename polyseam/frappe-containers
```
..the preview suggests that it will do the right thing:
```
? Rename polyseam/containers to polyseam/frappe-containers? Yes
```
...but the repo gets renamed wrongly:
```
✓ Renamed repository polyseam/polyseam-frappe-containers
```
This adds an upfront validation that looks for a slash and tells
you that the command can't transfer a repo.
Fixes#10034.
