3 ms·

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. Mos

by 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?

by i386 10y ago

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?