Upon further review, this uses an observer pattern which is just completely different from what I was envisioning. I'm still glad I found it because it still captures the problem with visuals, and helps demonstrate demand for a solution.
Gerald R. Wiltse jerrywil...@gmail.com On Wed, May 20, 2020 at 11:09 AM Gerald Wiltse <jerrywil...@gmail.com> wrote: > It's worth noting that I think a lot of good code and abstraction and > capturing of the problem already exists here: > > https://plugins.jenkins.io/join/ > > I'm not sure if Stefan Wolf still watches this list or actively > contributes to Jenkins, but his insight would probably be invaluable. I > will study his work and try to reach out to him. > > Regards, > Gerald R. Wiltse > jerrywil...@gmail.com > > > > On Tue, May 19, 2020 at 10:30 AM Gerald Wiltse <jerrywil...@gmail.com> > wrote: > >> I find this feedback very encouraging. It definitely does seem to be a >> good candidate for JEP proposal. I will plan for that in the >> mid-term future. >> >> Your suggestions about alternatives are all right on. In one large >> environment, I created a solution with a metajob that received webhooks >> from all jobs, used the Jenkins REST API's to query "all job >> configurations" and then correlate the hooks to metadata, and use build() >> to trigger the appropriate jobs. This effectively represented an >> alternative downstream mapping mechanism. It worked for it's purpose and >> is still in production today. In the end, we looked back and squinted at >> it, and could see that with a few very deep, yet reasonable (likely >> non-breaking) changes to the upstream/downstream system , Jenkins could do >> the same logic natively. That largely led to this thread. Right now, I'm >> engineering a solution for a different use case which is similar-in-scope, >> related to the topic, yet different enough to learn some new things. At >> the end of this, I think I will have an even better mix of perspectives to >> guide me through a JEP. I apologize in advance for bothering everyone in >> the future with my struggles on creating the reference implementation. >> >> To everyone reading, I would still like to collect support for this >> effort in terms of votes and comments and other peoples struggles in the >> Issue I linked. >> >> Regards, >> Jerry >> >> Gerald R. Wiltse >> jerrywil...@gmail.com >> >> >> >> On Mon, May 18, 2020 at 5:55 PM Jesse Glick <jgl...@cloudbees.com> wrote: >> >>> 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 >>> . >>> >> -- 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/CAML1RCCXJnK1XhbHTAGnnq92ER0xqCssNb3XeJke9nZC53ZLcg%40mail.gmail.com.
