Sergei, I love the visualization this provides of the pipeline DAG! One thing worth mentioning: I have been working on a scalable/high-performance & parallel-aware FlowAnalyzer for pipeline stage view that is generalized enough to assist with the data you are visualizing. Since the rest-api portion of stage view is available as a separate plugin from UI, I might suggest consuming that API or its extensible Analyzer algorithm to power this view.
Advantages: don't have to roll your own API, get a variety of metrics on each FlowNode (pause/execution timing, status, executor used) and stage. The algorithm also scales to complex flows with thousands of nodes and implements caching for executed runs. Finally it supports limiting the number of FlowNodes returned for a stage, so one can render a subset where a stage contains a loop (or deeply nested blocks) returning thousands of nodes. Thoughts? On Monday, March 21, 2016 at 2:52:04 AM UTC-4, Sergei Egorov wrote: > > Hey everyone, > > Yesterday I decided to publish sources for my pipeline visualization > plugin: https://github.com/bsideup/jenkins-pipeline-view > > <https://lh3.googleusercontent.com/-t28IjO2m73U/Vu-VVrauoEI/AAAAAAAAAyI/tiF8TH7YVCYiqI4n78DvC0FQ21ir46LNg/s1600/screenshot.png> > > > What's cool about it? > First of all, it *can handle any graph* provided by pipeline because it > uses very powerful *JS graph library* to position steps. > Also, it's a *React* application, written in *ES7* (not even ES6!), with > ImmutableJS and RxJS inside - so hipsters will be happy :D But in fact, it > means that it's damn easy to develop this plugin and provide more > functionality. > I use *Webpack* to bundle everything (JS, CSS, fonts, images, SVG icons) > in one single pipe.js file. *No Jenkins JS Modules*, no conflicts, no > impact on others. Even CSS will not conflict because of *CSS-modules* ( > http://glenmaddern.com/articles/css-modules ) > All icons are SVG ones and look good on any screen, retina or not, and any > zoom level. > > I use Jackson on the backend side to serialize FlowNodes and their > actions. *Why Jackson?* Because it was much easier to implement > serialization of selected (non-exposed) fields and class info included > compared to Stapler. I saw something were done about classinfo in Stapler, > but at the moment of creation of this plugin, it wasn't delivered to > Jenkins core yet. Also, *almost none of the Pipeline actions are > @Expose-d*. > > I use *gradle-jpi-plugin* instead of Maven because it's much easier to > describe some complex build process with Gradle, especially when frontend > build is involved. In fact, it's just one line: > > https://github.com/bsideup/jenkins-pipeline-view/blob/954b895b6574cdf34815ff94a4a8db3ad3811aeb/build.gradle#L61 > > > Future development > Will I continue to develop it? Definitely! Here, *at ZeroTurnaround*, we > use Jenkins a lot, and eventually we will migrate to the pipelines, and > proper visualization of the process is a must for us. And feel free to > contribute as well, it's really a good chance to learn *modern JS stack* as > well :) > > > > Best regards, > Sergei Egorov > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/9b0c2cbd-e6ec-4ae0-9b51-956d92f80b1f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
