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.