5 ms·

Well the weather icons do have meaning - they are a historical indicator of how successful your build or deployment process is. We show these along side the col

by i386 10y ago

Well the weather icons do have meaning - they are a historical indicator of how successful your build or deployment process is. We show these along side the color accessible status indicators except on the non-personalized dashboard. On the dashboard, they indicate the historical health of your most important branch (e.g. Master)

BinaryIdiot 10y ago
Maybe it's me but I don't care about historical health. For my projects I only care about its current health because anything Jenkins builds is going to successfully build (when it doesn't it's a fluke because we shouldn't be checking in broken things). Not sure if I'm in the minority here or not though but it actually bothers me if, say, I misconfigured something, build breaks, I fix it but now it's showing it's cloudy. It also took me way too long to realize that cloudy meant it built but failed in the past. I remember my first experience with Jenkins trying to figure out why the build was failing before realizing it wasn't failing and cloudy somehow meant it's good.
- i386 10y ago
  Noted - let me have a think about that. Might be worth having a look at the Personalised Dashboard in the blog again - that always shows the current status. Most screens refer either to the status of each branch or a specific job result. for the former a single status indicator wouldn't be appropriate. But what I'm hearing is the non-Personalised dashboard may be a point of contention.
  - curun1r 10y ago
    I'd like to add a me too comment, but with another thought about historical build health. It's not that I don't find it useful, but I'd rather see it along with my other metrics rather than included in the UI of my CI tool. If Jenkins could be used as a Grafana source or were able to export build metrics to Influx/Prometheus, people could use existing tooling/dashboards to display build health over time while keeping the main Jenkins UI clean and focused on the current state of the builds. Also, and I apologize if this is no longer how the Jenkins weather indicators work, but the last time I used Jenkins, the weather indicators were based on the number of failed builds, not the time the build wasn't green. For me, the number of failed builds is far less interesting than the amount of time that the build was failing. If a developer scrambles with three checkins in 15 minutes that attempt to fix the build and the third one succeeds, that's a better situation than a developer who takes a more measured approach that fixes the build four hours later on the first checkin. The first developer might have created a slightly messier commit history, but the second developer blocked the entire team for half a day. Taking the view that historical build information is really time series data would, to me, be much more insightful.
    - JoeAltmaier 10y ago
      Team members should have sandbox builds available. Its maybe not true that the integration build is blocking everybody. I don't think this statistic is worthwhile. Just knowing its broken, and making steady progress on integrating a working system, is often enough.
    - sciurus 10y ago
      You can expose some metrics via https://wiki.jenkins-ci.org/display/JENKINS/Metrics+Plugin https://wiki.jenkins-ci.org/display/JENKINS/Metrics+Plugin but not the per job success and failure counters you'd need to build what you suggest. That would make a good addition.
  - i386 10y ago
    Curious why you need sandbox builds if you've got builds per branch?
- stephenconnolly 10y ago
  So the point here is that the weather icons are slightly misunderstood and underused. Way back in the way back, a colleague and I were looking to get some extra information onto the Jenkins (then Hudson) jobs screen. I had some chats with KK over IRC and at the time he did not want to open up having multiple columns in the jobs screen. His then view of the world is that the jobs screen should be somewhat opinionated and clean. So I said, well what about if we add just a second icon beside the status ball and if you hover over it you get a tooltip that displays some detail message. KK said that didn't seem so bad... so off hacking I went. What I wanted was a kind of health column that would tell you the worst health of your job at a glance. The idea we had was that some jobs may have low test coverage, some jobs may have a flaky build, some jobs may have lots of TODO comments in the code, etc. So you would define the criterial levels of each metric and score jobs against those levels. Then we would pick the worst score and display an icon for that score. So off looking for icons I went... keeping in with the Tango theme that was used by the project at the time... My initial idea was that you would maybe have a heart that gets into worse and worse shape as the score went from 100% to 0%... but the red colour was too distracting... So I soon realized that - unlike the status balls - we wanted something that was not quite as high a contrast. You want to see the status balls first... if something is yellow or red, you fix that first... only when everything is blue do you want to start looking at the health (which is why the column is called "H") What I did find is that the weather icons gave me 5 levels of "health" and were subtle enough not to distract from the red and yellow balls... plus my colleague and I thought it would be really cool to have the code coverage metric be an umbrella and as the code coverage gets worse the umbrella would loose bits of fabric so that 0% coverage would be a tattered frame. So I had my patch and submitted it to KK and it got merged and the rest is history. For the initial patch I wanted there to be something for every job already, so the default job health is based on the last 5 builds (because there are only 5 levels of the default icons, and scanning any more would just be pointless) We also added contributors for the code coverage plugins and the violations plugin (which my colleague was the initial author of) Then of course you get distracted in other things... What disappoints me greatly is that in the 700 or so releases of Jenkins that have had the weather icons... nobody has actually gone and implemented the custom icons for job health feature that is embedded directly in the code and was available from the very first day the patch landed... I don't know if this is because the weather icons are just enough... or if it is because nobody noticed that you can do that... I know for the code coverage icon, neither Peter nor I are good enough artists to come up with 5 levels of umbrella in various states of disrepair... another idea was a pie chart or a small trend graph... but we always seemed to have more important things to do... and since I joined CloudBees I've been too busy to get back to that area. So anyway, I guess my point is that the weather icons were designed to be more subtle than the build status and the API was designed to allow plugins to contribute their own health and even their own icons... but whatever about other plugins contributing to health reports... nobody has bothered to contribute the customized icons! -Stephen (the originator of the weather icons in Jenkins)
oblio 10y ago
I like the weather icons. In less disciplined environments (most likely the majority of dev environments) they help nudge people by showing that the track record is less stellar than the green icon shows. Please keep them :)
- i386 10y ago
  That was certainly the use case that I had in mind for keeping them around. Need to weigh this up more but I am glad you like them regardless.
  - oblio 10y ago
    If it helps, I can actually provide several data points from companies I've worked for. I've managed 3 (4?) large Jenkins installations and after the initial exploration almost all developers I've worked with understood what the weather icons meant and liked them. Managers definitely liked them :)
    - tomfennelly 10y ago
      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)?

by i386 10y ago

BinaryIdiot 10y ago

Maybe it's me but I don't care about historical health. For my projects I only care about its current health because anything Jenkins builds is going to successfully build (when it doesn't it's a fluke because we shouldn't be checking in broken things). Not sure if I'm in the minority here or not though but it actually bothers me if, say, I misconfigured something, build breaks, I fix it but now it's showing it's cloudy. It also took me way too long to realize that cloudy meant it built but failed in the past. I remember my first experience with Jenkins trying to figure out why the build was failing before realizing it wasn't failing and cloudy somehow meant it's good.

i386 10y ago
Noted - let me have a think about that. Might be worth having a look at the Personalised Dashboard in the blog again - that always shows the current status. Most screens refer either to the status of each branch or a specific job result. for the former a single status indicator wouldn't be appropriate. But what I'm hearing is the non-Personalised dashboard may be a point of contention.
- curun1r 10y ago
  I'd like to add a me too comment, but with another thought about historical build health. It's not that I don't find it useful, but I'd rather see it along with my other metrics rather than included in the UI of my CI tool. If Jenkins could be used as a Grafana source or were able to export build metrics to Influx/Prometheus, people could use existing tooling/dashboards to display build health over time while keeping the main Jenkins UI clean and focused on the current state of the builds. Also, and I apologize if this is no longer how the Jenkins weather indicators work, but the last time I used Jenkins, the weather indicators were based on the number of failed builds, not the time the build wasn't green. For me, the number of failed builds is far less interesting than the amount of time that the build was failing. If a developer scrambles with three checkins in 15 minutes that attempt to fix the build and the third one succeeds, that's a better situation than a developer who takes a more measured approach that fixes the build four hours later on the first checkin. The first developer might have created a slightly messier commit history, but the second developer blocked the entire team for half a day. Taking the view that historical build information is really time series data would, to me, be much more insightful.
  - JoeAltmaier 10y ago
    Team members should have sandbox builds available. Its maybe not true that the integration build is blocking everybody. I don't think this statistic is worthwhile. Just knowing its broken, and making steady progress on integrating a working system, is often enough.
  - sciurus 10y ago
    You can expose some metrics via https://wiki.jenkins-ci.org/display/JENKINS/Metrics+Plugin https://wiki.jenkins-ci.org/display/JENKINS/Metrics+Plugin but not the per job success and failure counters you'd need to build what you suggest. That would make a good addition.
- i386 10y ago
  Curious why you need sandbox builds if you've got builds per branch?
stephenconnolly 10y ago
So the point here is that the weather icons are slightly misunderstood and underused. Way back in the way back, a colleague and I were looking to get some extra information onto the Jenkins (then Hudson) jobs screen. I had some chats with KK over IRC and at the time he did not want to open up having multiple columns in the jobs screen. His then view of the world is that the jobs screen should be somewhat opinionated and clean. So I said, well what about if we add just a second icon beside the status ball and if you hover over it you get a tooltip that displays some detail message. KK said that didn't seem so bad... so off hacking I went. What I wanted was a kind of health column that would tell you the worst health of your job at a glance. The idea we had was that some jobs may have low test coverage, some jobs may have a flaky build, some jobs may have lots of TODO comments in the code, etc. So you would define the criterial levels of each metric and score jobs against those levels. Then we would pick the worst score and display an icon for that score. So off looking for icons I went... keeping in with the Tango theme that was used by the project at the time... My initial idea was that you would maybe have a heart that gets into worse and worse shape as the score went from 100% to 0%... but the red colour was too distracting... So I soon realized that - unlike the status balls - we wanted something that was not quite as high a contrast. You want to see the status balls first... if something is yellow or red, you fix that first... only when everything is blue do you want to start looking at the health (which is why the column is called "H") What I did find is that the weather icons gave me 5 levels of "health" and were subtle enough not to distract from the red and yellow balls... plus my colleague and I thought it would be really cool to have the code coverage metric be an umbrella and as the code coverage gets worse the umbrella would loose bits of fabric so that 0% coverage would be a tattered frame. So I had my patch and submitted it to KK and it got merged and the rest is history. For the initial patch I wanted there to be something for every job already, so the default job health is based on the last 5 builds (because there are only 5 levels of the default icons, and scanning any more would just be pointless) We also added contributors for the code coverage plugins and the violations plugin (which my colleague was the initial author of) Then of course you get distracted in other things... What disappoints me greatly is that in the 700 or so releases of Jenkins that have had the weather icons... nobody has actually gone and implemented the custom icons for job health feature that is embedded directly in the code and was available from the very first day the patch landed... I don't know if this is because the weather icons are just enough... or if it is because nobody noticed that you can do that... I know for the code coverage icon, neither Peter nor I are good enough artists to come up with 5 levels of umbrella in various states of disrepair... another idea was a pie chart or a small trend graph... but we always seemed to have more important things to do... and since I joined CloudBees I've been too busy to get back to that area. So anyway, I guess my point is that the weather icons were designed to be more subtle than the build status and the API was designed to allow plugins to contribute their own health and even their own icons... but whatever about other plugins contributing to health reports... nobody has bothered to contribute the customized icons! -Stephen (the originator of the weather icons in Jenkins)

oblio 10y ago

I like the weather icons. In less disciplined environments (most likely the majority of dev environments) they help nudge people by showing that the track record is less stellar than the green icon shows. Please keep them :)

i386 10y ago
That was certainly the use case that I had in mind for keeping them around. Need to weigh this up more but I am glad you like them regardless.
- oblio 10y ago
  If it helps, I can actually provide several data points from companies I've worked for. I've managed 3 (4?) large Jenkins installations and after the initial exploration almost all developers I've worked with understood what the weather icons meant and liked them. Managers definitely liked them :)
  - tomfennelly 10y ago
    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)?