Renovate: Support recreating unmergeable branches in GitLab

[rarkins]

GitLab doesn't support low-level git API like GitHub, so currently we mark every PR as canRebase=false. But it would perhaps be desirable to close existing PR and create a replacement, instead of leaving the existing one as conflicted.

Cc @guumaster

[guumaster]

Depends on your GitLab version, ut turns out that Gitlab EE has the feature, but its not exposed through the API.

[rarkins]

In that case I guess we can't use it though? BTW I have been testing against the public gitlab.com myself

[hutson]

The public GitLab.com site is their Enterprise Edition.

For what it's worth, I would lean on the side of not using any specific EE features as there are a lot of non-profits out there using GitLab Community Edition, and they too may benefit from renovate.

[Autre31415]

With npm5 out and package-locks being a default feature this issue has become a whole lot more relevant.

So far my workflow to handle this manually has been to nuke the conflicting branch and re-running renovate which generates a new branch with the same name and links to the original PR. This is not perfect however as we lose an updated description and title in the case of newer versions of deps being added during this process.

If we can overcome that drawback automating the branch nuking may be a viable solution though.

What do you guys think?

[rarkins]

we lose an updated description and title in the case of newer versions of deps being added during this process.

Could you give an example of this so I understand?

[Autre31415]

It would be a bit challenging to stage the scenario myself. But the steps to reproduce this naturally would be:

1. Having a fairly stale PR waiting in the queue that has a merge conflict (Usually due to package-lock now)
2. Deleting the source branch (Without deleting the PR)
3. Running renovate, which will detect the out-of-date dep and go ahead and make the branch again.
4. The PR is now live again, and if there just so happened to be a newer version of the dep than the original PR reflected renovate would have committed to that newer version, but the title and description of the PR will not reflect this, only the latest commit message will.

[rarkins]

@Autre31415 Are you saying that in GitLab you can delete a branch and it does not automatically delete/close the MR?

If so then this behaviour differs from GitHub but that would be a good thing and help me solve the problem.

[Autre31415]

That is correct, and that has been my manual solution to dealing with this problem, with the only drawback being that the title and description will not update if the dependency has a newer version when the branch is remade. If that can be fixed then I think this is a good solution to handling this issue.

[rarkins]

That's quite possibly the trick we need then.

So:

1. We have a conflicting branch/MR
2. We delete the branch. "Zombie" MR stays open!?
3. We recreate the branch, based off of master - no conflicts
4. GitLab "reconnects" the zombie MR with its recreated branch?
5. Renovate needs to detect the MR and update its title/description

The strange thing is that (5) is meant to be the way things work already. If you're sure it's not - or was it just theoretical - then hopefully it can be fixed. FYI: renovate will check the MR title and description on every iteration and update it if the old one is outdated.

[Autre31415]

I can confirm through my own use of renovate that 2 and 4 are the case, with 5 being the only problem. I've been dealing with this problem since npm5 dropped and package-lock created merge conflicts galore.

The zombie MR will include a message that the branch was deleted, but will remain open with no changes or commits listed.

[rarkins]

Thanks for the info. I think it can be fixed and the end result will hopefully be as elegant as the existing GitHub rebasing.

[rarkins]

I'm looking into this now. I think an easy way to reproduce such a challenge in an empty repo is:

1. Install a version of dependency 2 versions old (e.g. [email protected])
2. Run renovate (will create 2 MRs, one for each major version)
3. Merge the 3.x branch
4. The 4.x will now be in conflict

[rarkins]

Confirming how it looks to me when I delete the branch:

And after running renovate again it relinks:

[rarkins]

Nearly done. You get a bit of "noise" in the "Discussion" area but otherwise it's quite elegant:

[rarkins]

@Autre31415 please try renovate version 8.38.0 and let me know how it goes. It should automatically delete and recreate any branches that have got into unmergeable state (e.g. due to package-lock.json.

BTW in case you have "related" packages causing this problem (e.g. eslint and friends), consider having a package "group" to put them all into the same branch and avoid the merge/rebase/merge/rebase cycle when multiple are released at similar times.

Example: https://github.com/singapore/renovate/blob/master/package.json#L109-L118

[Autre31415]

🎉 🎉 🎉 🎉 🎉 🎉

I just tried it out and am happy to report that our merge conflicts are being handled properly now, and with updated descriptions. Awesome work!

[rarkins]

Great news! Thanks for tip re: how GitLab let's you delete branches without automatically closing the MR - that was the whole reason why I couldn't do the same thing on GitHub and assumed the same for GitLab.

[hutson]

Also wanted to chime in and say what an awesome enhancement!

The extra discussion updates are a minor matter given the enormous benefit.