Describe the bug
Apparently, using {owner}/{repo} in a local clone of a forked repo results in the original repo, at least in gh api.
I'm not sure whether this is intended behavior or not, since the documentation says "will get replaced with values from the repository of the current directory", hence the "apparently" in the above.
If this is intended, it should really be documented, and in addition, I think that there should be a way to either run verbosely (I don't see such options in gh api --help) or show some warning output.
(I question whether this is intended, since it just sounds like a very strange behavior. But I'm sure that there was some reason for doing that, and that stuff will break if it changes.)
Steps to reproduce the behavior
In my case, I have a workflow script that runs
gh api "repos/{owner}/{repo}/compare/master...foo"
This works fine from a non-forked repo, but in a forked one, the result is a comparison in the original repo rather than the current one. This makes leads to a bogus result in a forked repo for the same action.
I verified that using a literal owner/repo of the forked repo is identical to the above, and using $GITHUB_REPOSITORY instead fixes this, at least as much as getting the expected behavior.
Expected vs actual behavior
Expected the local repo owner/name, but it uses the original values.
Describe the bug
Apparently, using
{owner}/{repo}in a local clone of a forked repo results in the original repo, at least ingh api.I'm not sure whether this is intended behavior or not, since the documentation says "will get replaced with values from the repository of the current directory", hence the "apparently" in the above.
If this is intended, it should really be documented, and in addition, I think that there should be a way to either run verbosely (I don't see such options in
gh api --help) or show some warning output.(I question whether this is intended, since it just sounds like a very strange behavior. But I'm sure that there was some reason for doing that, and that stuff will break if it changes.)
Steps to reproduce the behavior
In my case, I have a workflow script that runs
This works fine from a non-forked repo, but in a forked one, the result is a comparison in the original repo rather than the current one. This makes leads to a bogus result in a forked repo for the same action.
I verified that using a literal owner/repo of the forked repo is identical to the above, and using
$GITHUB_REPOSITORYinstead fixes this, at least as much as getting the expected behavior.Expected vs actual behavior
Expected the local repo owner/name, but it uses the original values.