Gitlab authentication confusion

[oliversalzburg]

I was trying to use a git+ssh URL as an npm dependency in one of our projects today. That git URL was pointing to our private, internal Gitlab server. So, naturally, the build failed, because strider didn't have access to the repo during the git clone phase.

I figured I would add a custom SSH key to the project, but had not much luck doing so, especially since just pasting my key into the textboxes wouldn't save it. I realized that, if I toggle a checkbox on the settings page, the key would be saved.

I continued to repeat the process for all our projects (as the dependency was to be used in all projects).

Afterwards, I realized that I was no longer able to clone any of our projects. I later realized that this doesn't make sense, because the cloning should use the deployment keys (which are properly installed for all the projects). So, what happened here?

When I installed a proper SSH key into /home/strider/.ssh, added a Strider user into our Gitlab, I was suddenly able to clone again. This was interesting, but not what I wanted.

While rebuilding our setup, I peeked into the database and realized that all projects had the property provider.config.auth.type set to ssh. I am currently assuming, that a different value should be set here for Strider to use the deployment keys.

[oliversalzburg]

Okay, so the ssh as the auth type is not generally wrong. While restoring, I noticed that project can be cloned just fine with that auth type.

However, I noticed that whenever I would re-create a project, there was an explicit port set in the git URL, which, I believe, slipped into the config while messing with gitlab during the day. I was convinced that it shouldn't be there. As it turns out, Strider caches git repo URLs in users.accounts.cache, which is probably cause for a lot of confusion I was experiencing today.

[oliversalzburg]

I'm still in the process of rebuilding and the confusion doesn't stop.

I now have 2 projects, the first one I recreated yesterday night and it clones just fine:

$ git clone --recursive git@…/nexus.git . -b dev
Cloning into '.'...
$ git checkout -qf dev
…

The second one doesn't clone:

$ git clone --recursive git@…/mobile.git . -b dev
Cloning into '.'...
Permission denied (publickey).
fatal: Could not read from remote repository.

What's confusing here is that the relevant configuration for both projects seems identical to me:

I'm not sure what other part of the setup is playing a role here.

[oliversalzburg]

The other part that is playing a role, are the SSH keys. The deployment key Strider installs in gitlab is the SSH key it generates when you set up the project.

It will then use the SSH key from the project settings for authentication during the clone process. But I had changed that key in the project settings, so the keys would no longer match up, because the new keys aren't installed into gitlab.

[oliversalzburg]

Generating a new keypair doesn't resolve this issue either. Which even makes me believe that generating a new keypair will most definitely break your setup because the new key isn't set as a deployment key.

[oliversalzburg]

What I was actually trying to do was pretty much #572

[knownasilya]

Looks like a much desired feature

[oliversalzburg]

I might have a go at it, but, I would need to learn more about how the frontend works first.