The build pipeline plugin has, for a long time, supported displaying both downstream projects (e.g. projects triggered from the publishers section, either using the default downstream build support from Jenkins "Build other projects", or one of the Parametrized Trigger Plugin's trigger steps "Trigger parametrized builds on other projects"), and also displaying subprojects, which can be added from the builders section, after installing the Parametrized Trigger Plugin, as a "Trigger/call builds on another project".

Both downstream builds and subproject builds are displayed identically in the build pipeline, without any visual way to distinguish between them. This can get confusing, specially if a job has both downstream builds and subproject builds. Additionally, because subprojects can be defined as blocking (that is, the build step doesn't complete until the triggered project has finished, something that can't be done with downstream builds), this can get even more confusing, as you can see multiple pipeline builds executing simultaneously.

For example, suppose we have three jobs, let's call them JobA, JobB, and JobC, and they are configured as follows:

• JobA will have a build step which will call JobB as a blocking subproject.
• JobA will have a publisher which will trigger JobC as a downstream build.

This will be shown in the build pipeline as shown in the attached screenshot. The pipeline will show both JobB and JobC at the same level, as if they were executed in parallel (when the reality is that JobB runs first, then after it finishes, JobC is ran). Additionally, when the pipeline is ran, during some time, both JobA and JobB will be shown simultaneously, while in reality JobA is blocked by the execution of JobB.

Obviously everyone has distinct requirements, and I'm sure that for some the current behavior is fine. I propose to add an option to just hide the subprojects, leaving the downstream builds only. While this may not be ideal for some, it has some benefits:

• In the most common use call (which is configuring JobB as a blocking subproject that will cause JobA to fail if it fails, as if it was a function call), we are not losing information in the pipeline, because in case JobB fails, we will see JobA's failure in the pipeline.

• Jobs are no longer displayed as if executing in parallel.

• Only one pipeline step is shown as executing simultaneously.

• It is probably easier to implement than any of the other solutions.

If I get some time to work on it some day, I will submit a PR, just asking for feedback right now.