Pipeline
This page shall give you an overview of what you can do with the pipeline. Also have a look at Menu Bar which gives a short description for each button in the menu bar. Last but not least Context Menu explains what functionality you get when you invoke the context menu on a project or command in the pipeline.
The focus of the analysis and thus the resulting pipeline is not (yet) put on project analysis as such (e.g. report unresolved dependencies, vulnerabilities, usage of different versions etc.). However, we detect cycles (which are problematic for releasing) and pom properties which cannot be resolved and warn about them. And to a certain extent you can use it to analyse dependencies between projects and to get an overview over your project landscape. Following the resulting pipeline taken from the online example
Every box is a maven project where multi-module projects contain inner boxes which represent their submodules. Each toggle signifies a command which will be executed if you click on Start Release. For instance, project dgr-3 has a command JenkinsUpdateDependency with dgr-4 as dependency. This command will update the pom.xml of dgr-3 and update the version with the newest version of dgr-4. The submodules dgr-3-b and dgr-3-c have also a dependency to dgr-4 (have a look at Known Limitations, we do not (yet) support all kind of version updates).
As you can see in the above example, the pipeline might give you already some hints for improvements.
For instance, it would probably make sense to add dgr-4 to the dependencyManagement section of dgr-1 instead of managing the version in dgr-3-b and dgr-3-c in addition.
The main focus of the pipeline is of course releasing projects. You can deactivate certain commands if you do not want them to be executed. Notice that if you deactivate a command that the release command is automatically disabled as well. You can also use the toggle on top of the project to (de)activate all command of the corresponding project.
In case you make modifications (such as changing a release version for a certain project or deactivate a command), you need to save your changes first before you can start the release. Once settled you can click on Start Release and let the pipeline do the rest.
You will see that the root project (the one on the outer most left) will change its status from Ready to Queuing (icon changes to orange), from Queueing to InProgress (green play) and eventually from InProgress to either Succeeded (green check) or Failed (red exclamation mark). If it has succeeded then it dependent projects will be triggered etc.
Once you have released everything then you will have a nice looking green pipeline:
You can click on the status icon to go to the corresponding Jenkins job (already during state InProgress) to the the error.
Luckily for you, the pipeline supports retriggering commands. This means you can fix errors and use the Start Release button which is now named Re-trigger failed Jobs. Let us look at an example.
Two projects failed, dgr-5 and dgr-2. Nonetheless, it continued executing commands of dgr-1 which are not affected by these failures. Notice that the vertical bar lines are a visual help in case you have to release manually (for whatever reason). In such a case we recommend that you use the pipeline as release plan and release one project after another where you can release projects in the same column in parallel. The pipeline as such is way more efficient and triggers commands as soon as a dependency is released. As an example, updating the dependency dgr-3-b in the project drg-1 is done as soon as dgr-3 is released and does not wait until dgr-2 is released.
As side notice, we used the Explore Release Order button to generate this view and played around with window['dep-graph-releaser-gui'].failAfterSteps which lets you fail a command by will 😉 in the simulation.