Work on MRs from different projects in parallel

[okainov]

Would be great to be able to work asynchronously with MRs from different projects

[nirizr]

I think my PR #293 might be helpful for this

[okainov]

@nirizr at least from the description I'm not sure it does what expected. Within the single project I see it as making sense to merge chronologically, this issue was more about multiple independent projects...

[nirizr]

I'm not sure I follow. Within a single project you say you rather Marge bot wait for a single MR until it passes CI although other MRs are already ready to be merged? I'm curious, why wouldn't you want a ready MR to be merged?

You're correct that right now this won't help you, though.

[okainov]

Within a single project you say you rather Marge bot wait for a single MR until it passes CI although other MRs are already ready to be merged? I'm curious, why wouldn't you want a ready MR to be merged?

I'm not against it, it might be useful feature :) But in our team we do use rebase-only approach and it's better to have defined order of automatic merges than "fight who is faster to pass ci".

The ideal thought for a single project was that whatever merge tool does, it might build some kind of "merge train" inside itself to avoid multiple rebuilds. So if I have 3 ready-to-merge MRs, ideally it should build "virtual" branch which has all three merged and use this in order to validate the 3rd PR.

[nirizr]

I was only asking out of curiosity, it's also perfectly fine if you're against this as a feature :)

And I see why in a rebase-only flow you'd find this an inconvenience. Thanks!

[laurence-hudson-mindfoundry]

This feature would be really useful for my org, we frequently make new repos, and setting up an extra instance of marge each time has become a pain. We toyed with using the project regex stuff, but that just resulted in MRs from different projects being unnecessarily delayed by each other.

I had a stab at making marge support this on a fork and it seems to work (we're using one concurrent marge across a few tens of repos at the moment). I'm not a python guy so its pretty hacky, before I invest time in cleaning it up for an MR, is this a feature smarkets would be interesting in taking, or is this better just staying on my hacky fork?

Diff: laurence-hudson-mindfoundry@170d9e2
Dockerhub: laurencehudsonmindfoundryai/marge-bot-test:test3

[snim2]

@laurence-hudson-mindfoundry In our instance of marge-bot, the project regexp is just .* and we don't create a new instance of marge-bot for new groups or projects, we just add the marge-bot user to the group/project with maintainer privileges.

This does mean that long-running CI pipelines can "hold up" other MRs, but it does keep everything very simple.

[laurence-hudson-mindfoundry]

@laurence-hudson-mindfoundry In our instance of marge-bot, the project regexp is just .* and we don't create a new instance of marge-bot for new groups or projects, we just add the marge-bot user to the group/project with maintainer privileges.

This does mean that long-running CI pipelines can "hold up" other MRs, but it does keep everything very simple.

Yeah we went down that route for a while, but the delays introduced where just too high, hence the fork.

[snim2]

Yeah we went down that route for a while, but the delays introduced where just too high, hence the fork.

Right, I feel your pain! I can't remember whether Marge sets merge when pipeline succeeds after it's pushed a rebased version of each MR, but that might speed things up a little.

[nicolas17]

I can't believe it doesn't already work that way, if I hadn't found this issue I wouldn't have known until trying marge-bot in production 😐

You're saying it will currently wait for CI to finish in one MR, merge it, and then rebase the next MR in the queue even if they are on different projects?