GH should not require git repository to exist where operation does not affect one

[arcivanov]

Describe the bug

I've attempted to use gh run cancel <id> from a directory that was not a repository.
While the cancel operation would've proceeded normally due to having GH_TOKEN in the env, gh started balking at not being in a git repository. When I initialized the directory with git init as a workaround, gh run cancel further complained there were no remotes in the repository.

Case 1 (empty dir):
https://github.com/karellen/karellen-llvm/actions/runs/9047154513/job/24858809382#step:2:26
Case 2 (git init with no remotes):
https://github.com/karellen/karellen-llvm/actions/runs/9047223038/job/24858879136#step:2:39

Version is 2.49.0.

Steps to reproduce the behavior

The exact code is linked above in the publicly accessible workflows.

Expected vs actual behavior

Expected: GH CLI has no git repository requirements for operations not affecting git repositories.
Actual: GH CLI performs git repository validation for operations not affecting git repositories.

Logs

Linked above in the action runs.

[arcivanov]

Doing git init followed by git init add remote <url> is a workaround for this problem.
Here are the logs of the functional workaround: https://github.com/karellen/karellen-llvm/actions/runs/9047299097/job/24859062533

[williammartin]

Unfortunately the REST API does require the repo ID which is why the CLI needs to know the repo to which the run belongs. However, instead of initialising a git repo I would suggest you use gh cancel run -R [HOST/]OWNER/REPO <ID> which will be used in place of interrogating your filesystem for a git repository.

[arcivanov]

let me try that, thanks!

[arcivanov]

While I'm trying it, gh can also do what I'm going to do is use GITHUB_REPOSITORY and GITHUB_SERVER_URL env variables to determine the host/owner/repo.

[arcivanov]

https://github.com/karellen/karellen-llvm/actions/runs/9049315253/job/24863292405#step:2:25

This worked, thank you!

I still think that in the presence of GITHUB_SERVER_URL and GITHUB_REPOSITORY there should be no need to query git. The order should be -R, env vars, git.

[andyfeller]

While I'm trying it, gh can also do what I'm going to do is use GITHUB_REPOSITORY and GITHUB_SERVER_URL env variables to determine the host/owner/repo.

I still think that in the presence of GITHUB_SERVER_URL and GITHUB_REPOSITORY there should be no need to query git. The order should be -R, env vars, git.

@arcivanov : My largest concern with this idea is unintended consequences because we don't know what is going on in someone's GitHub Actions workflow and environment variable have higher priority over the details gathered from the local repository the command might be executed in.

I've worked in workflows that have 2 separate Git repositories checked out and involve syncing content between them. If gh were to listen to GITHUB_REPOSITORY, it would break my automation because env variables override the directory I'm in. At least with GH_REPO, it is something explicitly GitHub CLI related and a last resort as people will use -R,--repo for one-off commands, only setting this env var when there are several commands involved.

As for GITHUB_SERVER_URL, I think that is something I could be talked into though I'm unsure what percentage of GHES users are hitting GHES resources over anything on Dotcom. So maybe less impactful but would want to get feedback from the community and other customers before making such a change.

[arcivanov]

What would the unintended consequence be?
Current behavior:

1. If -R use -R settings
2. Query the local git and fail if not a repository.

New proposed behavior:

1. If -R use -R settings
2. Query the local git, records the failure but don't propagate it.
3. If [2] fails, look at env variables.
4. If [3] fails, propagate the failure from [2]

All current behaviors will be preserved. Since in the current behavior [2] is the end of the line, there are no other possible state-machine behaviors a user could've had to begin with.