Now that we know how to run pipelines, we can test the script that we created in the previous chapter using the Blue Ocean pipeline editor. Simply copy the script (found in the GitHub repository) and copy it into the Script field. A little warning here, pipelines can cause deadlocks! A pipeline needs a node to run on, but then spawns separate builds for the individual stages. So when your pipeline is running on the Linux node and a stage requires the Linux node as well, but the Linux node is configured to only run one build at a time, the stage will wait indefinitely for the Linux node to become available again. Make sure you always have at least one more executor on your nodes than you have pipelines. Unfortunately, it is currently not (yet?) possible to trigger pipelines on a specific node, so you can have a node specifically for building pipelines. That way, you can build stages on other slaves and you would be sure stages would never be waiting on their host pipelines to finish.

We can now run the script from the previous chapter. You will notice that there are indeed two builds triggered. Too bad you cannot see which build is the pipeline and which build is the stage:

Funny thing, this script runs three test stages in parallel. The script still only has one test stage node though, so the stage view will still only show one stage, but this will show as completed as soon as one of the tests completes.

You can still see the three different test stages running in the Jenkins build overview though:

The script should run fine. Since we have scripted the GitLab trigger, you should now also see that configured in the project configuration even though you only pasted the script. For this trigger to work properly, you still need to create a webhook in GitLab by the way. Once you do that, you will even see that your build status is updated in GitLab. If you script anything like a Git trigger or polling, you need to run the script at least once to enable it: