After merging in upstream changes regarding local extensions, this commit addresses remaining PR feedback while also bringing the newly merged tests into alignment with other changes.
- Local extensions on Windows are not symlinks but files whose contents is the path to the local extension directory
- Local extensions elsewhere are symlinks
- this was something I did in the original implementation of this improved extension update notification logic
- discovering other parts of the extension manager code that were working with non-prefixed extension names motivated a different approach
- the extension manager code that requires the extension be prefixed has been enhanced to use the centralized ensurePrefixed() logic, making the need for this on the extension unnecessary
- extension manager has been made responsible for extension update directory information
- extension manager has been enhanced to ensure that previously left extension update metadata is deleted before installing an extension
- extension manager has been enhanced to ensure that extension update metadata is deleted when extension is being removed
- refactored extension command tests for manager change, ensuring previous and expected states along with returned release info
- refactored extension manager tests for ensuring previous extension update entries are removed before installing extension
- created extension manager test for installing local extension
- centralized logic for checking and ensuring extension name is "gh-" prefixed
First pass at implementing basic test around extension state checking behavior, wanting to discus with team about level of testing to perform and whether this is really the right place.
Instead of returning `ErrExtensionExecutableNotFound` error which causes `gh` to have a non-zero exit code, catch it and print the message to stderr, returning nil. Only print the warning to stderr when there is a TTY.
This commit is a bit of refactoring to bring the extension update checking logic up to par with what is done with `gh` including creation of state file per extension and listening to env vars for disabling version checking.
This work is not complete as it does not address necessary test changes.
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.
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.
However, to provide better support for Macs running on Apple
Silicon, it will
[fall back](78c1d00ecc/pkg/cmd/extension/manager.go (L267-L274))
from `darwin-arm64` to `darwin-amd64` if
[Rosetta](https://support.apple.com/en-gb/102527) (Apple's
compatibility layer) is installed.
If Rosetta isn't installed, this fallback doesn't happen, which
can lead to surprising and confusing results when one Mac has
Rosetta and another doesn't, because the extension will install
on one machine but not another.
In the situation where a `darwin-arm64` binary isn't available
but the CLI can't fall back to `amd64` because Rosetta isn't
installed, this updates our error message to suggest installing
Rosetta.
Closes https://github.com/cli/cli/issues/9592.
