[oniro] MR rebase fails occasionally

Summary

Sometimes, rebasing an MR results in UI failing with the following reported error:

Merge failed: Rebase failed. Please rebase locally. Please try again.

Immediately retrying the rebase (through the same UI button) works but the UI gets stuck into Checking if merge request can be merged… loading state. A page refresh shows that it actually succeeded and the new pipelines were triggered.

Steps to reproduce

I am not aware of a way to reproduce it. The last time it happened to me was on this (eclipse/oniro-core/oniro!214 (merged)) MR @ 2022-07-21 ~13:25 UTC+01:00.

What is the current bug behavior?

Rebase functionality seems unstable - even when there are no conflicts.

What is the expected correct behavior?

Rebase should work when no conflicts are generated.

Relevant logs and/or screenshots

See above.

added prioritylow severitylow statetodo team:releng labels

removed prioritylow label

removed severitylow label

(removed this is another issue)

added IT-prioritylow IT-severitylow labels

When this problem occur again, can you provide me the link to the MR, without manually rebase.

As this MR has been merged manually, commit hash has changed too (eclipse/oniro-core/oniro!214 (merged))

Globally, gitlab can't rebase by himself most of the time, because commit tag history hash has changed in the target branch, so it can't reconcile.

It can happen, while you push directly to the target branch without MR, or a CI job who push with git client while another MR is accepted.

eclipse/oniro-core/oniro!214 (merged) was not merged/rebased manually. As I've stated above, it was all done through the UI making the initial error a false positive of some sort. This issue is about rebases failing when there is no rebase conflict.

And by merge I think you mean rebase as the MR has not been merged yet.

@heurtemattes I just got into this now with this MR: eclipse/oniro-core/oniro!214 (merged). It failed with Rebase failed: Rebase locally, resolve all conflicts, then push the branch. Try again. but the rebase would raise any conflicts so I'm sure that if I retry it would work as explained above.

in kirkstonebranch, there is 3 commits not present in your branch. So I mean there is a conflict when gitlab try to apply patch that need to be managed manually, if not gitlab is lazy on rebase over MR, which not surprise me.

I'll take a look at gitlab logs, if I see something specific to this rebase. But not sure I can do any action, it's internal to gitlab.

kirkstone branch:

Your branch:

@heurtemattes That is not what a conflict is. A git conflict is when a certain operation results in the inability of applying a change/patch. It is the event when the system, GitLab in this case is not able to automatically resolve differences in code between two commits. What you are describing above is a branch diverge. And that is correct, kirkstone and the incoming branch in the MR have diverged and that is why GitLab is offering a rebase button (per our project's configuration requirements). This entire issue is about the fact that this functionality - GitLab rebase - doesn't seem to work consistently. In this MR's case, there is no conflict in place. The system wrongly advertises that there is a conflict but retrying the rebase button a couple of times completes the rebase operation without any conflicts proving that the initial error is incorrect (wrongly reported by GitLab). That is precisely what I've just done in eclipse/oniro-core/oniro!214 (merged). I have retried the rebase button a couple of times and succeeded at some point - no manual pushes, fixes, conflict revolves or any related optations were involved.

As such, I disagree that this is an expected GitLab behaviour. In my opinion, this strikes as an obvious bug.

added statewip label and removed statetodo label

changed the description

assigned to @heurtemattes

@agherzan we're going to make some configuration changes in gitlab, that we'll apply later this day. Let me know if this happens again after!

I put a due date to next Wednesday, to keep this issue visible.

changed due date to July 27, 2022

I've implemented the change (postgres max_connections increased). Let's see if this happens again.

I'll keep an eye on this for the next couple of days and come back with some feedback. Thanks for looking into it.

I don't think anything got improved sadly. Just now on the eclipse/oniro-core/oniro!246 (merged) MR I got the same behaviour:

1. Activated the "Rebase" button and the UI errored out with "Rebase failed: Rebase locally, resolve all conflicts, then push the branch. Try again."
2. Click the same button again - same error.
3. Refresh.
4. Click the same button - passed all good.

Again, no manual rebases were involved. The MR has no conflicts with the destination branch so GitLab should (and eventually does) be able to handle this directly from the UI.

changed due date to August 05, 2022

changed title from MR rebase fails occasionally to [oniro] MR rebase fails occasionally

removed due date

unassigned @heurtemattes

assigned to @fgurr