Let's take a simple example of a typical pipeline. For every merge to the
master branch of your GitRepo, you need to:
Single step approach
Technically, you can bundle all these steps into one
Bash step. Your pipeline diagram will be a single step, triggered by a change to your
The approach above has the following characteristics:
Multiple steps approach
Let's look at an alternative approach to the same pipeline using a combination of native steps and
As you can see, the pipeline has a much more discrete structure and each step can send its status notifications.
You can also run the "run tests" step on a node with a custom runtime, or even split it up into parallel steps if needed.
This is the recommended approach to define steps that are sufficiently discrete to be able to perform interim actions such as identify status, send notifications, and evaluate results.