I’m not personally a fan of it, I’m not too sure how much value it gives to the end user. It doesn’t scale particularly well nor does it support theming.
I’d be in support of removing it, any thoughts?
I don’t use it either.
But since the content is shown on a separate page it does not hurt if we continue to deliver it. Or is there something in it that blocks progress on the rest? You never know who is using these kind of things …
I think aggregating the build history status of a job in a chart or timeline isn’t a bad idea per design, however the current implementation isn’t of use for me.
Navigating the timeline is a nightmare. The predefined dates and hours make it weird to use for cron jobs running every 7/14/etc. days.
Not to forget that smile-widgets is effectively dead for more than a decade.
1 Like
I don’t need the timeline on the build history page, but the table of builds below the timeline has been useful for finding and replaying builds that failed because an agent did not have enough disk space.
FTR I proposed that in [JENKINS-60866][JENKINS-71797] Remove timeline widget by daniel-beck · Pull Request #6869 · jenkinsci/jenkins · GitHub if someone wants to give it a try to see how it feels.
I also filed [JENKINS-60866][JENKINS-71797] Replace timeline widget with a maintained one by daniel-beck · Pull Request #8431 · jenkinsci/jenkins · GitHub due to lack of responses in the above PR (in case that was lack of agreement) but have no preference either way. Just the current widget needs to go due to CSP issues.
I hadn’t seen your PR Daniel (probably because it’s draft and no reviews requested, taking a look now)
1 Like
Depends on project and build time, you can estimate build time for larger builds
Late to the party, but just adding 2 cents worth …
The overall Build History is a very valuable resource for us. We have thousands of jobs configured in our instances, some running at scheduled times, some base on events and some manually triggered, some rarely run, some mutliple times an hour.
When something external to Jenkins goes wrong that impacts Jenkins, disk space was one mentioned example, but it can be other issues too, a comprehensive timeline of what was running over a given interval is a useful resource. As admins, we often use it to help determine the scope of impact and to proactively notify or correct (re-run) failed jobs, even before some teams may notice they were impacted.
However, as it stands now, the page is not terribly helpful. The graph only shows 10 lines by default and while expansible, is not scroll-able. As it tends to simply draw a rising trend that goes back “forever”, the visual utility of the chart is questionable. If anything, the list should scroll vertically and the timeline shifts in the background, lowest visible job fixed at the origin (if that makes sense to describe to you).
The value comes from the list of jobs below the chart. Unfortunately, that can take a long time to load and again shows a limited range (quickly checks one instance to see 887 runs listed in last 4 days; 3 days of which were long weekend, so usually that many easily run in a day).
Pagination on the lower list portion would be helpful.
Perhaps some sort of aggregation (by hour/day,etc.) or range selection (start / end date+time option) and some filter on status would also add value.
I would certainly be an advocate for just ditching the chart and improving the presentation of the list.
2 Likes