When installing an extension, the CLI must to select the correct
binary to download for the machine (see the
[`installBin` function](78c1d00ecc/pkg/cmd/extension/manager.go (L240))).
By default, the CLI will download a binary matching the current
machine's architecture.
If a suitable binary isn't available, the CLI
[outputs an error](78c1d00ecc/pkg/cmd/extension/manager.go (L278)),
directing the user to create an issue on the extension's
repository:
```go
if asset == nil {
return fmt.Errorf(
"%[1]s unsupported for %[2]s. Open an issue: `gh issue create -R %[3]s/%[1]s -t'Support %[2]s'`",
repo.RepoName(), platform, repo.RepoOwner())
}
```
The issue this creates isn't very clear or helpful. It isn't
obvious where it is coming from, or what you need to do.
This improves the suggested command, adding a better title
to the issue and an explanatory body.
To test this, try installing my
`timrogers/gh-extension-without-binary` extension, which only has
an esoteric `linux-ppc64` binary 😸:
```bash
gh extension install timrogers/gh-extension-without-binary
```
You'll get a nice output like this:
```
gh-extension-without-binary unsupported for darwin-arm64. Open an issue: `gh issue create -R timrogers/gh-extension-without-binary --title "Add support for the darwin-arm64 architecture" --body "This extension does not support the darwin-arm64 architecture. I tried to install it on a darwin-arm64 machine, and it failed due to the lack of an available binary. Would you be able to update the extension's build and release process to include the relevant binary? For more details, see <https://docs.github.com/en/github-cli/github-cli/creating-github-cli-extensions>."`
```
...which produces an issue like
https://github.com/timrogers/gh-extension-without-binary/issues/4.
I have tested the resulting command on macOS and Windows, so
I am confident that it has *at least reasonable* cross-platform
support.
Fixes https://github.com/cli/cli/issues/9600.
- doing mkdir before `git init <dir>` is not necessary; git will
create the directory if it doesn't exist
- passing both `-C` and `--git-dir` is not needed for git invocations
- reading the current working directory isn't necessary for specifying
nested paths to operate in
- use `git add .` instead of explicitly naming all paths; we generate a
gitignore for binaries that we want to avoid adding
- generate cross-platform gitignore for Go binary extensions
- add helpers to simplify writing files, tests
