Renovate: Cloning over SSH does not work

[orf]

What Renovate type are you using?

Self-hosted Renovate on self-hosted Gitlab

Describe the bug

Renovate will only attempt to clone over HTTPS. If your self hosted gitlab instance has disabled HTTPS cloning this will fail:

         "stack": "Error: Cloning into '.'...\nremote: Git access over HTTP is not allowed\nfatal: unable to access 'https://**redacted**@**redacted**.git/': The requested URL returned error: 403\n\n    at to

Did you see anything helpful in debug logs?

No

To Reproduce

Attempt to add a repository with https cloning disabled.

Additional context

This was apparently added in https://github.com/renovatebot/renovate/issues/2708 but it was broken at some point. This section of code always uses the http_url_to_repo.

I've also followed the instructions here: https://github.com/renovatebot/renovate/blob/master/docs/development/self-hosting.md#kubernetes-for-gitlab-using-git-over-ssh, which are apparently out of date.

[rarkins]

Could Renovate detect your SSH-only implicitly via the projects API? e.g. here's an example response from the GitLab API docs:

  {
    "id": 4,
    "description": null,
    "default_branch": "master",
    "ssh_url_to_repo": "[email protected]:diaspora/diaspora-client.git",
    "http_url_to_repo": "http://example.com/diaspora/diaspora-client.git",
  }

Is your http_url_to_repo null, or is there any other way to indicate that http cloning is not supported?

[orf]

You can only seem to detect this by hitting the admin only settings API, or by trying to clone it.

I think in some cases this is quite a common setting to enable on Gitlab (enforcing keys instead of usernames and passwords is a good idea, IMO).

And as it’s an instance wide setting, rather than project wide, having an environment variable or configuration setting to configure it makes sense.

[rarkins]

OK, I agree that if it's a global setting then we can support a global option. If we fixed up the option gitFs=ssh again then would Renovate be able to use the ssh_url_to_repo URL as shown earlier?

[orf]

Yep 👍

Obviously the user would need to ensure the right key is present in the container, but simply using the ssh URL from the api response would be enough.

[rarkins]

I had another case recently where a user didn't want us to use the http_url_to_repo, so an exception was added for this. I'm thinking to combine these into a single setting:

• default behaviour, which is to use http_url_to_repo
• ssh (your need), which is to use ssh_url_to_repo (and you handle adding the ssh key to the user/container)
• endpoint, which means ignore those URLs and use the configured endpoint directly

The configuration option name could therefore be gitUrl with enum values default, ssh, and endpoint. It would detect/migrate from the legacy env value if found.