During discussion in cli/cli#9934, we can to the conclusion that the logic around checking for core GitHub CLI updates would diverge from GitHub CLI
extension updates over time. To that end, this commit splits that logic into a separate function with a new environment variable.
- 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.
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.
This ensures that checking for newer versions of gh happens in the background of the main operation that the user requested, and that when that operation is completed, the gh process should immediately exit without being delayed by the update checker goroutine.
When the update notifier is enabled and a new version was detected, show
a Homebrew upgrade notice if:
- the release was at least 24 hours ago; and
- the current `gh` binary is under the Homebrew prefix.
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
