gitlab_uri setting not respected

[VannTen]

Description When using command such as glab repo clone <repo_path on self-hosted> installed, the gitlab_uri setting (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

• Version used : 1.16.0
• Operating System and version: Archlinux uname -a: Linux 5.11.15-arch1-2 #1 SMP PREEMPT Sat, 17 Apr 2021 00:22:30 +0000 x86_64 GNU/Linux

[profclems]

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]

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]

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

[clemsbot]

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]

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

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

[clemsbot]

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]

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.