Implement glab context

[solidnerd]

@profclems It's mostly specifying a base URL for your glab or we could have a similar feature like docker context or kubectl context where you can specify in which config context you are currently.

Default would be gitlab.com but as a user, I could define my own context for alpine as an example:

apiVersion: alpha/v1
instances:
- alpine:
    url: gitlab.alpinelinux.org
- gitlab-com:
    url: gitlab.com
contexts:
- context:
    instance: alpine
    user: alpine
  name: alpine
- context:
    instance: gitlab-com
    user: gitlab-user
  name: default
users:
- name: alpine-user
  user:
    token: "abc1234"
- name: gitlab-user
  user:
    token: "foobar"

Here is something that comes to my mind.

Originally posted by @solidnerd in #383 (comment)

[profclems]

I'm a bit tight at the moment. I will look at it later today so we look into it and see what to do

[profclems]

/cc @maxice8

[maxice8]

I don't have enough experience dealing with docker context or kubectl context and other context-type configuration to give an informed opinion at all.

[profclems]

@solidnerd thanks for your suggestion. Currently, this is the config format:

# global and host-independent configs here
...
...
# host related configs here
hosts:
    # gitlab.com is the default host
    gitlab.com:
        # What protocol to use to access the api endpoint. Supported values: http, https
        api_protocol: https
        # Your GitLab access token. Get an access token at https://gitlab.com/profile/personal_access_tokens
        token: *****
        git_protocol: ssh
    db.org:
        api_protocol: http
        token: *****
        git_protocol: ssh
    gitlab.alpinelinux.org:
        api_protocol: https
        token: *****
        git_protocol: https

which is not very far from the kubectl context format (quite far).

The configuration is used based on the host that glab finds in the git remotes. If none of the remotes is authenticated, then the user would have to authenticate the new host with glab auth login.

The limitation here is, the user isn't allowed to specify/choose/use a different host config for another host (this is where the context does best: being able to specify a config context to use at a time). Hardly will there be multiple hosts sharing a single host config (especially token) 🤔.

Implementing the context may take time because we'll be redefining the configuration format. It is a breaking change (or we would have to consider auto-migration at 'a first run' as we did for #170 but this would require translating the old format to the new format).

I would consider implementing glab context as a nice-to-have feature for glab.

Any suggestion on how best we can implement this?

[solidnerd]

Hey @maxice8 & @profclems,
Currently right now I don't know a proper solution out of my mind.

I would agree that it takes time, and we need to evaluate how it works for our use cases and others.

I propose doing it in the Feature Flag to test it and all the flows we need from our perspective or what happens during the test phase. I have no experience in writing a configuration mgmt on a context-based approach.

But I would like to involve myself here, but I can't say how much time I have for researching and building a POC for an estimation from the commitment point.
I'm in the lucky position that I got exactly this use case because I got two accounts on gitlab.com.

1 for work and 1 for personal things.

Let's see that we handle it over the next weeks and see how far we got there.

[profclems]

I have put this request on hold for now till we come up with a proper way of implementing this.

It's a nice feature and I believe it will make glab a lot more flexible if implemented properly. Can't say if this can be part of v2.0.0