feat: add additional git authentication rules

[Chumper]

Changes:

Add additional git authentication rules to the git environment.

Context:

We should support all common ways on how to fetch a repository.
This includes https and ssh.
When this is implemented it should solve some problems with docker sidecars not being able to fetch repositories because of missing private keys or missing tokens.
This makes it obsolete for bot users to somehow fiddle a ssh key into the side car containers.

Taken from:
https://coolaj86.com/articles/vanilla-devops-git-credentials-cheatsheet/

Documentation (please check one with an [x])

• I have updated the documentation, or
• No documentation update is required

How I've tested my work (please tick one)

I have verified these changes via:

• Code inspection only, or
• Newly added/modified unit tests, or
• No unit tests but ran on a real repository, or
• Both unit tests + ran on a real repository

[viceice]

Needs also real test runs

[Chumper]

Needs also real test runs

Will do and report back

[Chumper]

Tested on a real repo with a private repo: renovate-support/feature-13477#2
This only tests the https case because go will not use git@...

However the next step will be to add it to python, where python can use private repos with git@...

[rarkins]

Some doubts on the url changes

[Chumper]

We may need to defer this or use another solution.
I did a deep dive into git config and what it looks like.

Some things I found out:

• git config url."https://token@github.com/".insteadOf "https://github.com/"

  will be represented as the following in the config:

  [url "https://token@github.com/"]
    insteadOf = https://github.com/
  

  Which means that the insteadOf url is indeed the key that will be used for the lookup.
• The git config supports multiple insteadOf like this:

  [url "https://token@github.com/"]
    insteadOf = https://github.com/
    insteadOf = git@github.com:
  

  This helps us to have a single replacement url for all protocols we want to support.
  This can be set with the following commands:

  git config url."https://token@github.com/".insteadOf "https://github.com/"
  git config --add url."https://token@github.com/".insteadOf "git@github.com:"
  

  Notice the additional --add in the second command.
  This is needed to add the second value.
• The environment variables support no way of adding configs to a key.
  So the following will NOT work

  GIT_CONFIG_COUNT = 2
  GIT_CONFIG_VALUE_0 = url."https://token@github.com/".insteadOf
  GIT_CONFIG_KEY_0 = https://github.com/
  GIT_CONFIG_VALUE_1 = url."https://token@github.com/".insteadOf
  GIT_CONFIG_KEY_1 = git@github.com:
  

  This will result in the following:

  [url "https://token@github.com/"]
    insteadOf = git@github.dom:
  

  So the first option will be overriden.

In essence there is currently no way for me to add this feature with the same replacement url
This means that we can implement this feature but only partially for gitlab.

I would therefore suggest to keep the api, ssh and git usernames and treat the https replacement as priority.
That means that when the token is the same, only the https option will be activated because others are overriden.

[rarkins]

I like your idea of the workaround, and isn't it still superior to what we have now anyway?

[Chumper]

Yes, it would still be an improvement, my plan is the following:

• Add ssh, git as username in the url
• leave the https replacement as is without username (that is completely backwards compatible)
• Add the https replacement last, so that regardless if a username is given or not the https rule will always take priority

[Chumper]

Refactored the code according to the plan mentioned above:

* Add ssh, git as username in the url
* Leave the https replacement as is without username (that is completely backwards compatible)
* Add the https replacement last, so that regardless if a username is given or not the https rule will always take priority

[CLAassistant]

All committers have signed the CLA.

[viceice]

LGTM, but we should validate this with real tests against major platforms.

@zharinov Any hints for best testing this?

[viceice]

needs deconflicting

[zharinov]

Any hints for best testing this?

I know almost nothing about this particular subject 🤔🤷‍♂️

[Chumper]

@viceice We can test this once we implement this in python.
For golang it only supports https git repositories.
That's why the new additional rules will have no impact for the current implementation (which should only be golang)

Poetry supports git@ syntax as well, which this is the base for.
So when we introduce this for poetry I can run this agains a real repository.

If required, I can combine the two PRs into this one

[rarkins]

I think I'm OK to merge this as it appears backwards-compatible. Worst case it might makes some artifacts updating fail, but that's still a "soft" fail which should also be easily detectable.

[renovate-release]

🎉 This PR is included in version 31.67.0 🎉

The release is available on:

• GitHub release
• 31.67.0

Your semantic-release bot 📦🚀