This plugin is similar to a combination of the Build Blocker Plugin, Parameterized Trigger Plugin and perhaps the Block queued job plugin. It allows you to specify relationships between jobs and blocks them while downstream jobs are running or triggers them when upstream jobs are completed. Additionally it adds a graphical view of those relationships, similar to what the Build Graph View plugin does.
First and foremost, this plugin uses its own mechanism to track relationships between jobs which is independent of the job type. This means you can declare relationships for any job (like pipeline jobs (WorkflowJobs) for example), not just old-style-projects (AbstractProjects). Second, it uses its own namespace for the relationships, so you do not have to rely on the name of the job but can use any naming-scheme that suits your build-system (e.g. maven/gradle artifact ids). Third, it allows you to define conditional relationships; this means downstream-projects are only blocked if both the upstream- and downstream-projects share some attribute (e.g. they were started by the same user, triggered by the same upstream-project etc.).
Yes, this plugin is about building pipelines which span/consist of jenkins jobs. Unfortunally all the appropriate terms like pipeline, stage etc. have their specific meanings since the advent of the Pipeline Plugin. Additionally, most older plugins containing the term "pipeline" (e.g. the Build Pipeline Plugin) rely on Jenkins' builtin dependency-tracking mechanism which is restricted to old-style projects and will not work for jobs using the new pipeline jobs. Thus i've tried to find a term which expresses that this plugin spans jobs (which by themself might use a Jenkinsfile pipeline-script) and is independent of the known mechanism tracking project-dependencies. "Modules" is the best i came up with as a non-native english speaker. If you have suggestions for a better term, i'll appreciate it.
Let's say you've got a project with the following components:
Each component is built by its own job in Jenkins. Whenever there is a change to the component containing the component containing your common utilities or api you'll want to build and test the other components to see that your changes work for all of them. Currently you can model the downstream-depedencies using the Pipeline Build Step or or a Parameterized Trigger but this way the downstream projects will always be triggered if any upstream-project is completed. In this case the views-component is built three times; the first time when common is completed, the second time and third time when the model and the controller projects are completed. This plugin recognizes the dependencies and doesn't trigger the views-build until the controller-component finishes building. Additionally, when you make a change to both the common and the views-component at the same time, it blocks the build of the views-component until all its upstream-dependencies have completed their builds. When there are many developers you can configure the plugin so that it recognizes which changes originate from the same developer so that the pipeline are run in parallel for each set of changes.
This plugin uses code from the Build Graph View plugin and an adapted version of the DependencyGraph-implementation from Jenkins itself.