Issue accessing GH host with customized hostname

[yermulnik]

I have quite similar setup for my work GH EMU Org as described in cli/cli#6125 (url customization via InstaedOf via .gitconfig + custom SSH config via .ssh/config for the customized hostname).
Eventually (being auth'ed to my work GH EMU Org with GH CLI) when I try and run gh role I get this error:

2023/04/23 14:51:28 unable to determine current repository, none of the git remotes configured for this repository point to a known GitHub host

Any clue whether this is something to do with go-gh package or there's any option within gh-role to override "autodetected" GH hostname so that API calls use "correct" GH hostname instead of customized one?

Thanks

[yermulnik]

Oh, looks like if I pass -r cmdline arg with a value of [HOST/]OWNER/REPO (with placeholders replaced accordingly), I can get to overcome the issue. Though I'm still under impression that this should be resolved autoMagically by go-gh internally.
Vast majority of GH CLI commands that I'm aware of don't require me to provide host/repo as they are able to derive it from the repo config despite the customized GH hostname being used.
Closing this as I've found a resolution, though would be really great to get to the bottom of this and see whether it's something gh-role can handle or there's something that needs to be improved within gh-go. Thanks.

[nedredmond]

This is something I would like to investigate. Were you running the script in your repo's directory @yermulnik?

[yermulnik]

Were you running the script in your repo's directory @yermulnik?

Yep. Let me show:

> git rev-parse --show-cdup
../
> gh role
2023/04/27 23:00:49 unable to determine current repository, none of the git remotes configured for this repository point to a known GitHub host
> cd .. && git rev-parse --show-cdup && gh role

2023/04/27 23:01:15 unable to determine current repository, none of the git remotes configured for this repository point to a known GitHub host
> cd .. && gh role
2023/04/27 23:01:32 failed to run git: fatal: not a git repository (or any of the parent directories): .git
. error: exit status 128
> gh role -r my_org/my_repo
admin

Please do let me know if I can do anything to help investigating this.

[nedredmond]

@yermulnik, with the new release I've updated the APIs. The repo check should be more robust. Can you give it a try again?

I don't currently have a simple way to test against custom host names. If this doesn't resolve the problem, I'll create a custom host to test against.

[yermulnik]

No luck 😢

> gh extension upgrade role
[role]: upgraded from v2.1.3 to v3.0.0
✓ Successfully upgraded extension

> git remote -v
origin  github.com-myorg-EMU:myorg/devops-core (fetch)
origin  github.com-myorg-EMU:myorg/devops-core (push)

> gh role
2023/04/29 13:59:11 unable to determine current repository, none of the git remotes configured for this repository point to a known GitHub host

> git -C . config --get-regexp ^remote\.
remote.origin.url [email protected]:myorg/devops-core
remote.origin.fetch +refs/heads/*:refs/remotes/origin/*

> gh auth status
github.com
  ✓ Logged in to github.com as georgii-iermulnik_myorg (/home/giermulnik/.config/gh/hosts.yml)
  ✓ Git operations for github.com configured to use ssh protocol.
  ✓ Token: ghp_************************************
  ✓ Token scopes: admin:enterprise, admin:gpg_key, admin:org, admin:org_hook, admin:public_key, admin:repo_hook, delete:packages, delete_repo, gist, notifications, repo, user, workflow, write:discussion, write:packages

Some configuration details if they may help:

• My ~/.gitconfig has includeIf:

[includeIf "gitdir:~/data/github.com/myorg/"]
        path = ~/work/.gitconfig.myorg

• The ~/work/.gitconfig.myorg has insteadOf:

[url "github.com-myorg-EMU:myorg/"]
    insteadOf = g[email protected]:myorg/

• And ~/.ssh/config has this:

Host github.com-myorg-EMU
        HostName github.com
        User git
        IdentityFile ~/.ssh/myorg.key
        IdentitiesOnly yes

This "customization" presumably is the root of the "issue".
gh-role works w/o issues inside "normal" repos that have no URL "customization" configured.
At the same time none of GH CLI commands and extensions that I uses often suffer from this "issue" 🤷🏻

[nedredmond]

@yermulnik, I pushed up a pre-release just for you.

In most cases, the gh cli derives the host from your config. If that's not happening correctly, I've provided a way around it: specifying an enterprise hostname with a new flag.

Also, friendly outputs will have the full repo name, including the host. If we're still having difficulties, this will help us debug.

Thanks for your patience and your interest in my project! Let me know if this is working for your use case yet.

[yermulnik]

@nedredmond Thanks for taking a look into this. Appreciate this.

I pushed up a pre-release just for you.

How do I upgrade to the pre-release version? 🤔 It has no assets except the repo source code archive. Or am I supposed to clone repo and build the binary myself?

Also re the #13 (comment) — should I create a new issue for that or that is the intentional behavior? Thanks.

[nedredmond]

How do I upgrade to the pre-release version?

gh extension install nedredmond/gh-role --pin v3.1.0-pre
https://cli.github.com/manual/gh_extension_install#options

If this command doesn't work for you, you may need to update your gh cli. Looks like they just added version pinning in January.

But yeah, it does look like something weird happened with the release. I fixed it, so the above should work correctly now.

[yermulnik]

Oh, TIL! Thanks.
So i had to uninstall it first and then install pinned version.

> gh extension remove role
✓ Removed extension role

> gh extension install nedredmond/gh-role --pin v3.1.0-pre
✓ Installed extension nedredmond/gh-role
✓ Pinned extension at v3.1.0-pre

> gh role
2023/04/30 23:04:01 unable to determine current repository, none of the git remotes configured for this repository point to a known GitHub host

> gh role -hostname github.com
2023/04/30 23:04:37 unable to determine current repository, none of the git remotes configured for this repository point to a known GitHub host

> gh role -r myorg/devops-core
admin

[yermulnik]

you may need to update your gh cli.

> gh --version
gh version 2.28.0 (2023-04-25)
https://github.com/cli/cli/releases/tag/v2.28.0

[nedredmond]

The flag is just "host" but still disappointed it's not working from you.

Can you print a friendly version for me? gh role -f

That will let me know what host it thinks your repo is at.

[yermulnik]

The flag is just "host" but still disappointed it's not working from you.

> gh role -host github.com 2>&1 | head -5
flag provided but not defined: -host
Usage of /home/giermulnik/.local/share/gh/extensions/gh-role/gh-role:
  -f    Prints a friendly message. Otherwise, prints a machine-readable role name.
  -hostname string
        The host for which to check roles. If blank, defaults to the gh config. Note that you will need to be be authenticated for the host through the gh cli.

Can you print a friendly version for me? gh role -f

> gh role -f
2023/05/01 01:18:18 unable to determine current repository, none of the git remotes configured for this repository point to a known GitHub host

> gh role -r myorg/devops-core -f
georgii-iermulnik_myorg has admin role in github.com/myorg/devops-core.

[nedredmond]

Sorry about the flag confusion. I confused myself.

I'm perplexed. If you just run gh repo view, does that work for you?
Without the -r flag, I use GH's CLI API to get the current repo. It should work the same as gh repo. If the native GH CLI commands don't recognize your repo, there's not much that I can do, but at least we have the -r workaround.

[yermulnik]

I'm perplexed. If you just run gh repo view, does that work for you?

Yep, I mentioned this in the second message in this thread. This is the most confusing point about it.

> gh repo view | head -2
name:   myorg/devops-core
description:    This repository is used for DevOps jobs and infrastructure.

but at least we have the -r workaround.

Works for me. Thanks for taking time to look into this.
I think we can close this out at the moment. And maybe revisit it if there are others with alike issue.

What about #13 (comment)? It — in theory — might be related as the resolution of the repo name isn't much of an expectation to be honest.