Renovate: feat(gitlab): gitfs password auth

[viceice]

What would you like Renovate to be able to do?
I would like to use gitFs to commit files to branch with a selfhosted gitlab.

Describe the solution you'd like
We should have a config flag to allow using gitFs for committing files to a branch if we have a normal username and password as auth.

Describe alternatives you've considered
Use ssh, which is very complicated if gitlab is running in an docker container.

[viceice]

Currently commitFilesToBranch is forced to use the api if gitFs is http or https

https://github.com/renovatebot/renovate/blob/0038142cc2aed01cfe91207dcd1494f761327f4e/lib/platform/gitlab/index.js#L232-L235

[viceice]

Also the following produces much noise:
https://github.com/renovatebot/renovate/blob/0038142cc2aed01cfe91207dcd1494f761327f4e/lib/platform/gitlab/index.js#L242-L253

[rarkins]

GitLab doesn’t support write access via git over http/s so unfortunately this is not currently possible to support.

[viceice]

I'm using selfhosted gitlab-ce and git is working fine over https

[rarkins]

I might have slightly misremembered. I think it supports read-only git when using a personal access token. This page implies the same: https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html

Perhaps it supports read/write over https when a “real” password is used?

[rarkins]

Perhaps we would end up supporting two options for GitLab gitFs:

• password, which does read write through gitFs https
• token + ssh key, which does read write through gitFs ssh

BTW is setting up the ssh key for use with personal access token that much of a burden?

[viceice]

The ssh key is not the problem, but accessing the repository over ssh, because my gitlab is running within a rancher farm (docker). So ssh access is not exposed.

Ss gitlab-org/gitlab-ce#18106 stated, in gitlab pipelines the ci token has readonly repo access. With a usertoken with api access we should be able to push over http(s) as stated at limiting-scopes-of-a-personal-access-token.

[rarkins]

Right now there are three approaches possible for GitLab:

• Pure API
• gitFs over https for read, API for write
• gitFs over ssh for read/write

Pure API will be deprecated next major renovate release as there’s too many things which are hard or impossible when you need to fetch files one at a time via API.

If gitFs over https using the account’s “real” password works for read/write then we can support that in addition to supporting the gitFs over ssh using personal access token.

The ideal solution is for GitLab to support read/write using git over https with a personal access token but I’m not sure they plan to support that.

[rarkins]

@ViceIce are you willing to run Renovate using the "real" password of the Renovate user on GitLab? If so then this feature is feasible. If you can only run using a Personal Access Token then this feature is not, because GitLab doesn't support pushing via git using tokens.

[rarkins]

@ViceIce would you use a "real" password for this if given the opportunity?

[viceice]

@rarkins I can use the real password

[rarkins]

Thanks for confirmation. In that case I’ll work out how we can support both approaches

[rarkins]

Looks like GitLab will support write access with personal access tokens in release 11.11 (due in late May): https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/26021

Now I need to work out what that means to Renovate, because obviously we can't enforce people use the very latest version of GitLab.

These options could all work then:

• GitLab >= 11.11 with personal access token and gitFs=https
• GitLab < 11.11 with username/password and gitFs=https
• GitLab < 11.11 with personal access token, ssh key, and gitFs=ssh

[rarkins]

Thanks @horatiuvlad for adding the feature to GitLab :)

[viceice]

Can we check the API for the current version in init repo? The we can add simple if/else or switch/case.

[rarkins]

Seems like it: https://docs.gitlab.com/ce/api/version.html

[viceice]

Looks like we need an API scope token for that. We can try to get the version, if we don't get it we fall back to legacy behavior or we fail out with an error.

[rarkins]

Any existing tokens will also need to be updated with the write_repository scope too. I'm not sure there's any API available to query which scopes a token has.

[viceice]

But if the token already has the api scope, it will also have the write_repository scope. So all exising token should work.

[rarkins]

@ViceIce I have some doubts about that. The api implies it's for the API specifically, not necessarily the repository via git. You could probably test it out today by assigning a token with api only and seeing if it can git clone a private repo.

[viceice]

@rarkins I've tested with api token against gitlab-ce 11.10.1. working fine 👍

Additionally i looked at the diff from https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/26021.

• for gitlab < 11.11 we need api scope for git https? write
• fir gitlab >= 11.11 we only need write_repository for git https? write.
• we need api scope for MR and issue management. which will include all other scopes for now

https://gitlab.com/gitlab-org/gitlab-ce/blob/ca7815da29935460e466212a147c4cd52cab286a/lib/gitlab/auth.rb

[viceice]

I thought i'm using the password, but i configured to use a personal token with only api access.

[rarkins]

Thanks for confirming.

[viceice]

if opened a pr, which is working fine for me 😄

Should be improved

[viceice]

Thanks for confirming.

I've also verified by reviewing the gitlab-ce source code 😁

https://gitlab.com/gitlab-org/gitlab-ce/blob/v11.10.1/lib/gitlab/auth.rb#L276

So the gitlab mr only adds a new scope between read_repository and api scope

[renovate-bot]

:tada: This issue has been resolved in version 17.0.0 :tada:

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot :package::rocket: