tomfennelly

Could the current general lack of appreciation for them be related to where they are located in the Jenkins UI?

In Jenkins 1.x and 2.x they are visible on the top level dashboard alongside the green/blue orbs and I often wonder if that's a source of distraction because I (as a user) am looking at both of these indicators now and wondering how to interpret the state based on both of them, when maybe I shouldn't.

Would it help if the top level dashboard(s) contained only one general build status indicator (vs two), and then the trend/health indicators were "down" on the pipeline details page alongside other health/metrics info (static analysis info)?

Yeah, I personally have never found the weather icons to be very useful for many of the same reasons already outlined in this long sub-thread. If that's because I didn't "understand" them properly, well then that's a signal of UX failure imo.

I personally think that if users have to think too hard about what an icon (or status indicator) means, then something's not right with it and you need some other visualization for conveying whatever message it is you're trying to be convey.

For me, the weather icons have never passed that test because, at this stage, I've heard multiple people on different occasions say that they find them confusing. That, to me, tells me that they don't work and a different visualization is needed.

The popular/recommended pattern for using Jenkins pipeline is to abstract the course grained build "steps" out to shell scripts and to use Jenkins pipeline to orchestrate the whole build process by running these steps at the right time (in parallel blocks etc), capturing human approval, making it all "durable" (tolerant of restarts) etc etc. If you find yourself putting lots of complex build logic into a pipeline script, then you're probably doing something wrong.

Doing it this way reduces the tie to the "product" and also means that you can easily test the individual self-contained steps outside of the product.