Skip to content

Subtle issue with {repo} placeholder in forks #8273

@ebarzilay-godaddy

Description

@ebarzilay-godaddy

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    coreThis issue is not accepting PRs from outside contributorsenhancementa request to improve CLIgh-apirelating to the gh api command

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions