As far as I know there is no serious work in progress in this area, and no particular plan for work on it from the “core team” (maybe a misleading phrase).
Indeed `DependencyGraph` as currently defined is very rigid and could not work well even for moderately subtle Pipeline scenarios, so it does not seem worth trying to adapt. You can define more sophisticated variants of `ReverseBuildTrigger` in plugins, though I would tend to discourage doing this sort of thing at the Jenkins level to begin with. Instead it is likely more scalable to have “downstream” builds be triggered by some external event, such an artifact appearing in Nexus or an image in a Docker registry. Alternatively, you can keep trigger management outside of component Pipelines altogether, defining some sort of orchestration project that uses the `build` step internally but in a computed graph. Or this orchestration can be done by external tools designed for that purpose, for example using the Jenkins REST API to trigger builds. If some larger and more intrusive concept of dependency graphs needs to make its way into fundamental APIs so that a variety of plugins can interoperate based on a common understanding of project relationships (for example so the graph can be displayed in build visualizations), then someone would need to file a JEP for it and commit to writing a reference implementation and driving integrations. The added complexity would need to be justified by new abilities that a lot of people could enjoy without too much migration effort. Some inertia stems from the fact there is no obvious, straightforward, single best practice for doing CI when you have hundreds of interrelated components. Some organizations use a monorepo and use various tools to cache partial build results. Others prefer microrepos with subtle triggering relationships and special workflows. The build system often frames the problem. If you have a particular model in mind then you are in a position to sketch a tool which would help you and others in the same situation. -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr3oAz%2BFL%3D8FOXufOe0frmXiKeTP7WD9Jis%2BkwFCAkVvLw%40mail.gmail.com.
