Setting up gitlab token token for every project is annoying.
Please add support for switching GitLab instance based on git remote get-url origin. Using current branch if it is tracking remote branch would be the best.
I would like to have in settings only few tokens instead having many settings with same token.
Regarding the token, I'm not sure whether there is still an issue. We define token once per instance. I.e. all projects connected to the https://gitlab.com instance are going to use the one token that's defined for that instance.
The instanceUrl in settings could be in most cases correctly guessed from the git remote but there would be some edge cases (e.g. when using a custom port for the API, or when the SSH and HTTPS hosts don't match).
It is still a bit annoying if one has to work with multiple projects each of which may be in a different Gitlab instance (e.g., gitlab.com for personal projects and a private instance for company-related work). Even in a situation with only a private instance it is still a slight inconvenience to do the one-time instanceUrl setup after one has already provided a PAT for this private instance (i.e., the user has already specified the private URL once, why do they have to do it twice?).
A solution I had in mind is to find the intersection of git remotes hostnames and PATs hostnames, and if the intersection has exactly one hostname, use that as the instanceUrl, otherwise just do nothing. I believe it should already improve the UX a lot, and the edge cases could be taken care of separately.
@viktomas if this idea sounds good to you, I could take a stab at implementing it.
That sounds like a good first iteration @flood4life. I'm happy with you giving it a shot.
I have a suggestion though to even further limit the scope of the initial MR. Let's reuse the current fetchRemoteUrl() interface and try to match its result with the PAT hostnames (instead of looking for all configured remotes and doing intersection).
Reason for that suggestion is that the fetchRemoteUrl() logic is messy and refactoring it might increase the scope of the change too much. Especially since we only now start to work on automated tests (#199 (closed)) and we need to test every change manually.
I would be for UX similar to Git Config User Profiles plugin that allows you to setup your git name and email.
a) If there is no config and heuristic is 100% sure: Show notification with selected GitLab instance and button to change it (will trigger selection from next case).
b) Else show available instances to select from with additional Setup to new instance... option that would ask for url with preentered remote or converted from ssh and then ask for a token.
One other thing it could do is to wait for git config user profiles setup to complete and use git config email and/or name also for heuristic of which instance to chose from.
Or the other way around setup your profile based on token user info.
A year ago, @flood4life implemented a partial fix for this issue in !90 (merged) with matching configured token URLs with git remote host. Thanks again for that
So now when you don't define your gitlab.instanceUrl setting, GitLab Workflow tries to guess it (matching your tokens with your remotes) and if there's no match then it defaults to https://gitlab.com. Most of this happens under the hood without the user being notified.
I wonder whether this generally fixes the problem defined in this issue. If it doesn't, let's start a discussion to define the additional logic that should be put in place to make the detecting even more seamless.
a) If there is no config and heuristic is 100% sure: Show notification with selected GitLab instance and button to change it (will trigger selection from next case).
b) Else show available instances to select from with additional Setup to new instance... option that would ask for url with preentered remote or converted from ssh and then ask for a token.
For this me might want to first tackle the #459 (closed).
In general, we should come up with a flowchart of interactions before doing any implementation.
Today, we released an extension model redesign (in version 3.43.0) that matches GitLab instance URL from the token with the Git remote based on the host. It's also possible to manually assign any project to a repository (right-click on the repository item in the GitLab Workflow TreeView).
At the moment, this association can't be created using a command line or script. Please let me know what is your use case, how would you use a command-line interface?
We have a local gitlab instance and our urls for the git repo and gitlab are different. So git remote is something like git@git.something while the gitlab api is under something like https://gitlab.something.
Everytime I create a new vscode workspace and/or add a repo I have to manually set the gitlab repo.
Before this was easy. I set the parameter gitlab.instanceUrl to https://gitlab.something and everything works fine.
I have some different workspaces where I now have to change the gitlab repo.