search

profclems / glab

The GitLab CLI tool. Archived: now officially adopted by GitLab as the official CLI tool and maintained at https://gitlab.com/gitlab-org/cli. See https://github.com/profclems/glab/issues/983
https://glab.readthedocs.io/
MIT License
2.08k stars 163 forks source link

gitlab_uri setting not respected #686

Open VannTen opened 3 years ago

VannTen commented 3 years ago

Description When using command such as glab repo clone <repo_path on self-hosted> installed, thegitlab_urisetting (host:` in the config file) does not appear to be respected. It's also possible I misunderstood what that parameter does.

Expected Behavior vs Actual Behavior

Set up a config for a self-hosted gitlab instance : glab auth login --host <self hosted instance> Configure default gitlab_uri : glab config set -g gitlab_uri <self hosted instance> Try to clone a repo : glab repo clone <project path> Result : GET https://gitlab.com/api/v4/user: 401 {message: 401 Unauthorized} -> glab defaults to gitlab.com GITLAB_HOST=<self hosted instance> glab repo clone <project path> works like it should

From the glab config -h output, I expected the setting gitlab_uri to set a default instance glab would use for command which can not refer to an existing git remote (like repo clone). I have the feeling that's it's not supposed to work that way though, so it might be a documentation bug ?

Additional Notes The glab config -g set gitlab_uri <host> create a host: entry in ~/.config/glab-cli/config.yaml, why not a gitlab_uri: entry ?

Possible Fix

Either explicit the purpose of gitlab_uri or make glab select the correct host.

Related Issues

402 This is the one which made me think this was more a documentation issue than an unexpected behavior.

Your Environment

profclems commented 3 years ago

Hi @VannTen, thanks for reporting this issue.

glab repo clone only respects the environment variables for now (I will consider it a bug and fix it). So it whould work when you run

GITLAB_URI=gitlab.com glab repo clone <repo>

or

GITLAB_HOST=gitlab.com glab repo clone <repo>

https://github.com/profclems/glab/blob/7bf692a0b0696633aff8b449e6169f70ba7754a2/commands/project/clone/repo_clone.go#L106

The glab config -g set gitlab_uri create a host: entry in ~/.config/glab-cli/config.yaml, why not a gitlab_uri: entry ?

At the earlier stages of glab, we only considered gitlab_uri as the config key to set the URL of the GitLab instance. Later, we decided to respect GITLAB_HOST and GL_HOST as well. To support this, glab considers these three variables as a single host variable in the config key.

But when looking for host in the configuration, glab first looks for GITLAB_HOST => GITLAB_URI => GL_HOST in the environment variables before looking for host in the config.yml file.

https://github.com/profclems/glab/blob/7bf692a0b0696633aff8b449e6169f70ba7754a2/internal/config/config_type.go#L674-L675

clemsbot commented 3 years ago

This issue has been automatically marked as stale because it has not had recent activity. We haven't had the time to address it yet, but we want to keep it open. This message is just a reminder for us to help triage issues.

philippludwig commented 2 years ago

Stumbled on this today. Would be nice if this could be documented somewhere, it caused me about 30 minutes of frustration.

clemsbot commented 2 years ago

This issue has been automatically marked as stale because it has not had recent activity. We haven't had the time to address it yet, but we want to keep it open. This message is just a reminder for us to help triage issues.

jarrodu commented 2 years ago

I just ran into this issue too. Also, about 30 minutes of frustration.

Other than this, I am impressed with the project. 👍

clemsbot commented 2 years ago

This issue has been automatically marked as stale because it has not had recent activity. We haven't had the time to address it yet, but we want to keep it open. This message is just a reminder for us to help triage issues.

gitfool commented 2 years ago

I also got frustrated with this non-intuitive behavior, especially when you can specify the full url to the repo, which could be used as a hint to derive the host:

❯ glab repo clone https://mygitlab.com/mygroup/myrepo
GET https://gitlab.com/api/v4/user: 401 {message: 401 Unauthorized}

❯ GITLAB_HOST=mygitlab.com glab repo clone https://mygitlab.com/mygroup/myrepo
Cloning into 'myrepo'...
remote: Enumerating objects: 149, done.
remote: Counting objects: 100% (27/27), done.
remote: Compressing objects: 100% (27/27), done.
remote: Total 149 (delta 15), reused 0 (delta 0), pack-reused 122
Receiving objects: 100% (149/149), 72.77 KiB | 340.00 KiB/s, done.
Resolving deltas: 100% (94/94), done.

GITLAB_HOST is effectively redundant in this case.