Cannot fast forward merge

Summary

After update from 9.2.5 to 9.3.2-ee we cannot merge through the Gitlab interface.

Steps to reproduce

Project settings -> Merge method -> Fast-forward merge

Create a branch and a merge Request

The rebase button is always displayed

Make some changes in the branch

The rebase button is always there even if the branch is up to date agains master.

The merge button is invisible.

What is the expected correct behavior?

A merge button should appear if the branch is up to date against master.

The rebase button should be invisible if the branch is up to date against master

Relevant logs and/or screenshots

We have exact the same behaviour on 9.3.3-ee

added repository label

For those of you running into the issue, can you include your Sidekiq logs (/var/log/gitlab/sidekiq/current) and see if there are any errors with RebaseWorker?

Hi Stan, the log looks quite regular:

2017-07-04_17:46:18.33241 2017-07-04T17:46:18.332Z 1979 TID-ovsv4zrhs RebaseWorker JID-f22b2cd5bf883c73d933c57d INFO: start 2017-07-04_17:46:19.45123 2017-07-04T17:46:19.451Z 1979 TID-ovsv4zrhs RebaseWorker JID-f22b2cd5bf883c73d933c57d INFO: done: 1.119 sec

After that the loading spinner disappears and the rebase button is active again

Thank you very much Felix

added regression label

added Next Patch Release and removed regression labels

Another customer report: https://gitlab.zendesk.com/agent/tickets/79681

@fatihacet @psimyn I think this is a frontend problem. I reproduced the same problem, and the JSON looks right from the backend:

• can_push_to_source_branch: true
• rebase_in_progress: false

Is this caused by !2031 (merged)?

assigned to @psimyn

should_be_rebased (from backend) remains true after the request completes, so possibly due to that

I think this is the same issue as https://gitlab.com/gitlab-org/gitlab-ee/issues/1774 - the rebase is silently failing, only logs error to /admin/logs but not back to frontend

What's weird is that the actual rebase seems to have worked for me, but the MR itself still shows should_be_rebased is true?

Oh, it looks like PostReceive died in 9.3.3, which is why the MR never got updated. I think updating to 9.3.4 might help.

We have a similar error in https://gitlab.com/gitlab-com/runbooks/merge_requests/286 on 9.3.4:

Updating to 9.3.4 fixed my particular test. It looks like for me PostReceive was failing due to https://gitlab.com/gitlab-org/gitlab-ee/issues/2822.

@jamedjo As for https://gitlab.com/gitlab-com/runbooks/merge_requests/286, I see that branch is behind by a few commits. The current logic checks that that the merge request has a direct ancestor to the target branch. Does clicking on the Rebase button fix the problem?

removed Next Patch Release label

@felix.meyner Do you see any errors in the Sidekiq log with PostReceive?

@stanhu Rebase button results in Something went wrong. Please try again.

@jamedjo Odd, it worked for me. :)

removed assignee

@stanhu Yes we have corresponding error from PostReceive error.log

@felix.meyner Please upgrade to GitLab 9.3.5. That should solve the PostReceive problem.

@stanhu Upgraded to 9.3.5 the PostReceive errors are not shown anymore but the rebase button is still shown.

It looks like it's working again in 9.3.5.

We had to reboot the system a 2nd time after the upgrade. Now it looks fine for me.

@jean-francois.labbe Were you able to upgrade to 9.3.5 and test?

I'm seeing this exact behaviour on gitlab.com

I was seeing this yesterday, was able to fix it by closing and reopening the merge request.

Seeing same problem on gitlab.com

mentioned in issue #1774 (closed)

@smcgivern Can this be closed as a duplicate of https://gitlab.com/gitlab-org/gitlab-ee/issues/1774

@stanhu Thanks a lot it is working

@markglenfletcher I don't think it actually is a duplicate - the problem there is that when there is a 'legitimate' error, nothing is shown; and the problem here is that PostReceive wasn't working (which fixing #1774 (closed) wouldn't necessarily help with). However, it seems to be solved, so I will close it.

closed

Exactly the same issue as reported but with Gitlab 9.4 Rebase works but the merge button is invisible

reopened

@stanhu We upgraded to 9.4 and the rebase isn't working again

logs.txt

Maybe duplicate with #2979 (closed) ?

@felix.meyner This looks like a different problem. It says "the rebase button is always there even if the branch is up to date against master. The merge button is invisible." Although the animation on the report does look similar to #2979 (closed), however, it seems the problem in this issue is that the rebase button is presented even though no rebasing should be required.

@david.grant Maybe the rootcause is the same? In your ticket the you cannot fast forward merge.

Here we could because we have a clean history But in both cases the result of the rebase (an error or the positive response) is not processed by the frontend in both tickets.

@felix.meyner @jean-francois.labbe I think these are related. The rebase is working, but it is subsequently unable to update the MR (tracked in https://gitlab.com/gitlab-org/gitlab-ee/issues/2979).

If you close the MR and reopen it, it should reset the HEAD SHA we store for the MR, which will also make it realise the history is linear. I'm sorry that we broke this again - let's keep tracking the root cause in https://gitlab.com/gitlab-org/gitlab-ee/issues/2979

closed