SSH keys parameter is not optional

[okainov]

Why are SSH keys parameters required? I don't really want to do anything with it, I want to use bot purely with Gitlab API

[snim2]

Usually if you clone with the git@... URI you will need to have uploaded SSH keys to GitLab, in order to push to your repository. This helps GitLab verify that the programmer who is pushing code to the repo does have the identity and rights that they claim. IMO this is a feature, not a bug!

[okainov]

@snim2 I do not want to neither clone nor push with the bot! Why would I??? There is an API method to rebase MR and there is an API method to merge MR and I want bot to use them, not doing cloning for unknown reasons

[snim2]

Right, but I don't think that's how this bot works. It clones the repo, rebases against the target branch, rewrites the commit messages, pushes, then merges. So, it's going to need an SSH key. I'm not sure that you can configure marge-bot to work how you suggest, but it's worth reading through the README that covers the basic features.

[jcpetruzza]

The rebase method in the Gitlab api is a relatively recent addition (added less than an year ago), and until that point I don't think it was possible to write a merge bot that wouldn't have to clone the repo. While marge these days can optionally use the rebase api (this was added to handle merge requests from forks) there's still a lot of optional functionality that relies on having a local checkout in order to rewrite commits, etc.

It may be technical possible to have a mode of operation where no cloning is necessary, but this would need a bit of work

[okainov]

While marge these days can optionally use the rebase api (this was added to handle merge requests from forks) there's still a lot of optional functionality that relies on having a local checkout in order to rewrite commits, etc.

That was exactly my kind of suggestion - make SSH part optional and API part required.

With current Gitlab state itself it's quite impossible to use the bot in controlled environments without admin access (impossible to get impersonation/sudo token and overwrite approvers), which means in fact - no point in using SSH-related part. That's exactly the point in this issue - SSH should not be mandatory, but optional.

I'm not sure that you can configure marge-bot to work how you suggest, but it's worth reading through the README that covers the basic features.

I already did and ended my writing my own bot which was apparently quite simple :) Marge-bot is not fitting non-admin environments at all which is no-go for my team :)

[aschmolck]

As @jcpetruzza noted, this would probably require a non-trivial amount of work since some (important) features still require SSH keys and we need to also test that the combination of SSH-key-access/lack-of -access and requested features is valid (and provide informative error messages if not).

It would be nice to have that, but it's both work and adds complexity to the code base and tests, so I think it would require both someone stepping up to write a PR and at least some other users also voicing their interest in this feature.

All workflows we have at smarkets require SSH keys.

[okainov]

All workflows we have at smarkets require SSH keys.

What about "Use Gitlab API" option? I do expect that you use API here and not do unexpected clones and pushes

[JanMikes]

Hi, if bot cloned with https instead of ssh, the personal access token could be used instead and i believe it could completely replace ssh key.

I am using such feature in my own (other purpose) bot, repository uri is then:

https://<user>:<PAT>@gitlab.com/group/repo.git

[JanMikes]

Just noticed, there is already issue for exactly the same thing 😄 #225

[okainov]

@JanMikes it's not "exactly the same". Linked issue about cloning. My issue is about (implicitly) using no clone at all, because why?

[JanMikes]

I see, thank you for clarification - everything could be done via API.

[skycaptain]

I also vote for Marge Bot to only rebase and merge using the Gitlab API without cloning. Currently, the repository is always cloned nonetheless, which not only slows down the process (as we have rather large repositories) and takes additional ressources, I would also consider this a security risk as source code is unnecessarily and unwantedly checked out and laying around in docker volumes.