Bug? MR can be merged after only first result of several parallel pipelines

I’m looking to replicate a workflow I also use with GitHub. I am using GitLabCE 8.11.5.

I have Jenkins working with the GitLab-plugin via a webhook for each job. Normally, when a Merge Request is created, or updated, a Jenkins job is triggered by the hook and the MR will wait for that job to complete before allowing a reviewer to complete the merge.

What I want to achieve is for this mechanism to work for several parallel and independent Jenkins jobs. For example, one job to compile the source, one to run static analysis on the source, another to build docs. The way I have it set up, using a separate webhook configuration for each job, results in all the jobs being triggered correctly, but there’s an issue with the way GitLab handles each job’s result which can (and does) result in premature merge.

###Example
With current behaviour, it is not clear to a reviewer that subsequent results may be pending, as this example shows. An premature merge is a likely result.

For simplicity I have only two jobs working in the following discussion. The jobs run in parallel however the second is faster to complete than the first, and when it reports its status to GitLab, GitLab treats this as a “retry” of the first job, and incorrectly allows the MR to be merged early. When the second job completes, the result appears in the MR’s Discussion, however by then the MR may have already been merged. What I would expect to see is GitLab waiting for both jobs to complete, and only allowing the merge once both are successful.

####MR Created
A simple MR is created. GitLab posts to two webhooks, and both Jenkins jobs are run in parallel.

However the Builds tab shows only one entry. The hyperlink points to the second job:

####Fastest Job Complete

Once the second (fastest) job has completed, the Builds tab only shows this - there’s no indication here that the first (slower) job is still running:

Also, the merge button is now green:

####Both Jobs Complete

After both jobs have completed, the Builds tab now shows:

As you can see, the first job was marked as “retried”, although in fact both those hyperlinks (#335, #336) now point to separate and correct Jenkins jobs. However 336 is clearly not a “retry” of 335.

The order of this behaviour may be affected by the order I defined the web hooks. I have not investigated this further.

Conclusion

So my question is - does GitLab support multiple independent external builds as part of its MR process? If so, how do I modify the configuration so that GitLab does not treat the result of the second job as the result of the first? Or is this a bug?

If GitLab does not support multiple external builds (which would be unfortunate because it works really nicely on GitHub), I could perhaps use Jenkins to trigger all parallel jobs and report back a final status when they have all completed. Does anyone know of a suitable Jenkins plugin and configuration for this workflow?

EDIT: removed references and screenshots of Pipeline due to a misunderstanding I had about what this information means.

Replying to my own question:

I believe this behaviour is caused by the configuration of the GitLab Plugin in Jenkins. Each job has a “Publish build status to GitLab commit” post-build action. This has a field named “Build name”, and if this string is not unique amongst all the builds in the pipeline, GitLab gets confused. By changing these names to unique strings, the Merge button only becomes available once all jobs have completed successfully (provided no votes have been placed).

However, I still see only one entry in the Builds tab, until the first job has completed successfully, and then both appear (one as running, one as passed). Once the second job has completed successfully, both appear as passed. However this is minor and does not affect the review or merging process.