Gitlab merge request fast forward merge

Question

I'm trying to setup a gitlab worflow for my team with gitlab-ci. We have a Gitlab CE version 10.2.4 with gitlab CI configured to run a build on every push. Now we would like to use the merge request workflow with protected develop and release branches. Our requirement is that no code can be merged into these branch without running on gitlab-ci first to keep these branches clean.

Since gitlab doesn't seem to have the possibility to automatically test merge request, our only option is to use either Merge commit with semi-linear history or Fast-forward merge. (cf open issue on gitlab)

The issue is that since these merge option require fast-forward, if multiple merge request are created for the same target branch, accepting one merge request changes the target branch. This then prevent other merge request from being merged as they are no longer fast-forward. This means that every time we accept a merge request we have to rebase/merge all the other merge request with the target branch which is quite tedious.

Can anyone using Fast-forward merge option on gitlab explain how they deal with this multiple merge request scenario ? Or is there an other way to ensure that code is tested before being merge without requiring the fast-forward ?

Emilioemily

Answer 1

In your project settings, go to "General"->"Merge request" and check "Only allow merge requests to be merged if the pipeline succeeds".

Burgas

Thanks for the answer but we already used this option. The issue we had was that we needed to rebase manualy all awaiting merge request when we accepted a merge request. This has been mostly resolved with a new feature in gitlab allowing to rebase directly from merge request in the web interface which greatly simplifies the process. – Emilioemily

Answer 2

The feature that you are looking for is Merge Trains. However this is available only for "premium".

We use regular merge requests with regular pipeline that runs on the branch. This pipeline passing is a condition to merge the MR.

I agree that there is a possibility that two MRs will consist changes that each by itself will be ok but together will break something. However, from my experience, I do not think I saw such a thing. Even if it does seldom happen, I still prefer it over the annoyance of "Merge commit with semi-linear history" or "Fast-forward merge".

Nonsectarian