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.
When running `gh repo fork` in the context of an existing repo, the CLI offers to create a remote for the fork:
```
? Would you like to add a remote for the fork? Yes
```
If you accept, it prints a log stating that the `origin` remote has been created:
```
✓ Added remote origin
```
Where there is an existing `origin` remote, this is renamed to `upstream`, but this is done silently without any notification to the user.
```bash
$ git remote -v
origin https://github.com/timrogers/badger.github.io.git (fetch)
origin https://github.com/timrogers/badger.github.io.git (push)
upstream https://github.com/badger/badger.github.io.git (fetch)
upstream https://github.com/badger/badger.github.io.git (push)
```
It seems kinda fine to rename the remote without explicitly confirming since this is not a truly destructive action, but it should make it clear what it is doing.
This updates the logging to explicitly log about the renaming of
the existing remote:
```
✓ Renamed remote origin to upstream
```
Fixes#9982.
Refactor the logic for checking `workflow` scope checking in releases to be in the positive - check if the scope is there, not check if it isn't there. Then, when the function is called we invert it.
Also update comments to be more imperative.
This refactor also incorporates @andyfeller's suggestion to use `slices`.
Co-Authored-By: Andy Feller <andyfeller@github.com>
This commit expands filepathDescendsFrom(string, string) to handle edge cases such as mixing absolute and relative paths or artifact name edge cases.
Additionally, tests for filepathDescendsFrom() and downloadrun() have been expanded to verify additional use cases.
This incorporates the work done by @williammartin to improve reasoning about `gh run download` behavior through testing while verifying a simpler solution to checking if a path is contained within a directory.
