Add experimental 'Details' widget for builds #10147

janfaracik · 2025-01-13T09:35:09Z

Behind the experimental flag, new-build-page.flag, this PR adds a new 'Details' widget to build pages. The widget lists information about the build (currently just a small set for this PR), which makes it easy to see at a glance what caused the build, how long it took, and any relevant SCM information.

This is just a subset of the final information that could go into this widget, intended to keep the PR small and reviewable.

We have a new extensible API too, which allows plugins, such as the Git Branch Source plugin, to hook in to the Details widget to contribute its own Detail items.

Downstream PR here jenkinsci/github-branch-source-plugin#826 (Need to move the detail to scm-api will be done soon)

An example of what a more complete implementation of this could look like is seen in the Pipeline Graph View plugin:

Testing done

Details show as expected when the flag is enabled
No changes to the interface when the flag is off

Proposed changelog entries

Add experimental 'Details' widget for builds

Proposed upgrade guidelines

N/A

Submitter checklist

Give feedback

The Jira issue, if it exists, is well-described.
The changelog entries and upgrade guidelines are appropriate for the audience affected by the change (users or developers, depending on the change) and are in the imperative mood (see examples). Fill in the Proposed upgrade guidelines section only if there are breaking changes or changes that may require extra steps from users during upgrade.
There is automated testing or an explanation as to why this change has no tests.
New public classes, fields, and methods are annotated with @Restricted or have @since TODO Javadocs, as appropriate.
New deprecations are annotated with @Deprecated(since = "TODO") or @Deprecated(forRemoval = true, since = "TODO"), if applicable.
New or substantially changed JavaScript is not defined inline and does not call eval to ease future introduction of Content Security Policy (CSP) directives (see documentation).
For dependency updates, there are links to external changelogs and, if possible, full differentials.
For new APIs and extension points, there is a link to at least one consumer.
Options

Desired reviewers

@jenkinsci/sig-ux

Before the changes are marked as ready-for-merge:

Maintainer checklist

Give feedback

There are at least two (2) approvals for the pull request and no outstanding requests for change.
Conversations in the pull request are over, or it is explicit that a reviewer is not blocking the change.
Changelog entries in the pull request title and/or Proposed changelog entries are accurate, human-readable, and in the imperative mood.
Proper changelog labels are set so that the changelog can be generated automatically.
If the change needs additional upgrade steps from users, the upgrade-guide-needed label is set and there is a Proposed upgrade guidelines section in the pull request title (see example).
If it would make sense to backport the change to LTS, a Jira issue must exist, be a Bug or Improvement, and be labeled as lts-candidate to be considered (see query).
Options

core/src/main/java/hudson/model/details/DurationDetail.java

core/src/main/java/hudson/model/details/TimestampDetail.java

core/src/main/java/jenkins/model/Detail.java

daniel-beck · 2025-01-13T12:10:23Z

core/src/main/java/jenkins/model/Detail.java

+    /**
+     * Returns true if this detail is applicable to the given Actionable object
+     */
+    public boolean isApplicable() {


For Action this would be the job of the factory. Why create an object just to discard it?

That's fair, I was using isApplicable to encapsulate show/hide logic of the detail inside of the Detail, so that its factory didn't need to worry about that.

daniel-beck · 2025-01-13T12:10:47Z

core/src/main/java/jenkins/model/DetailGroup.java

+    public static DetailGroup SCM = new DetailGroup(0);
+
+    public static DetailGroup GENERAL = new DetailGroup(Integer.MAX_VALUE);


Why are these not @Extension(ordinal = …)?

src/main/js/pages/job/index.js

core/src/main/java/hudson/Functions.java

daniel-beck · 2025-01-13T12:19:48Z

core/src/main/java/hudson/Functions.java

+            details.addAll(taf.createFor(object));
+        }
+
+        Map<DetailGroup, List<Detail>> orderedMap = new TreeMap<>(Comparator.comparingInt(DetailGroup::getOrder));


This is so weird only because it doesn't use @Extension.

daniel-beck · 2025-01-13T12:20:32Z

core/src/main/java/hudson/Functions.java

+
+        for (Detail detail : details) {
+            if (detail.isApplicable()) {
+                orderedMap.computeIfAbsent(detail.getGroup(), k -> new ArrayList<>()).add(detail);


Not extensible if it doesn't handle getOrder clashes gracefully.

daniel-beck · 2025-01-13T12:22:50Z

This doesn't look finished enough for a security review, but so far with what's there, there's no concern from my side. @timja Is there specific code that triggered you to label this as needing review that I may have missed?

timja · 2025-01-13T13:53:57Z

This doesn't look finished enough for a security review, but so far with what's there, there's no concern from my side. @timja Is there specific code that triggered you to label this as needing review that I may have missed?

Not really wasn't 100% if it was needed, thanks for the feedback

uhafner · 2025-01-13T22:07:27Z

Since the current summary is an non-configurable mess I wonder how we can make it better in the details widget now?
What is the difference between the new details widget and the summary widget?
How can we enforce that the UI of a detail element is just a line with a text and icon? Otherwise we get the same thing as in the summary...
Is there a configuration planned? (Order, Visibility)

timja · 2025-01-13T22:37:54Z

Since the current summary is an non-configurable mess I wonder how we can make it better in the details widget now?

What is the difference between the new details widget and the summary widget?

Summary widget is basically 'Uncategorised' from the Manage Jenkins page.
The plan is to add some high level cards and then allow plugins to add their own as well.

I'm thinking for the next core ones:

Changes (Jan has something for this I think mostly working)
Artifacts

Plugin ones:

Test results (potentially in the junit plugin or maybe a test-api plugin)
Code coverage
Static analysis warnings

Need to do a bit of analysis to see whats going on the current summary pane and needs to be there / should be removed.

e.g. we plan to get rid of all the Git Action data thats displayed there...

How can we enforce that the UI of a detail element is just a line with a text and icon? Otherwise we get the same thing as in the summary...

I think for the Details card anything else will look quite silly so potentially it will be fine because of the building blocks supplied.

Its possible we don't even need this pane to be jelly-able. We started out with it as Jelly but Jan's moved I think most of it to be done in Java now. I think the date format one is the only thing left in Jelly which could potentially be handled in another way if its worth it.

Is there a configuration planned? (Order, Visibility)

There's an order through code in this.
By configuration do you mean user configuration or extension configuration?

Potentially, we need to review more of what goes on the summary page.

uhafner · 2025-01-14T09:39:30Z

Is there a configuration planned? (Order, Visibility)

There's an order through code in this. By configuration do you mean user configuration or extension configuration?

I don't think that order by code will be sufficient. This will lead to the same problem as we have right now. Before we are developing new widgets we should better spend some time on how this can be configured by users. Like this has been done by e.g. Apple on IOS devices (and now on the desktop as well): first of all, they provided a fixed grid (tiles) and a user configuration of this grid. Users can change the size of the widgets (in terms of tiles), order of widgets, visibility of widgets. Not until they released this concept they added widgets step by step... Otherwise we get the same thing as now: too many widgets compete for the best place in the small visible area.

Co-authored-by: Tim Jacomb <[email protected]>

janfaracik · 2025-01-14T11:31:58Z

I don't think that order by code will be sufficient. This will lead to the same problem as we have right now. Before we are developing new widgets we should better spend some time on how this can be configured by users. Like this has been done by e.g. Apple on IOS devices (and now on the desktop as well): first of all, they provided a fixed grid (tiles) and a user configuration of this grid. Users can change the size of the widgets (in terms of tiles), order of widgets, visibility of widgets. Not until they released this concept they added widgets step by step... Otherwise we get the same thing as now: too many widgets compete for the best place in the small visible area.

Heya. Thanks for the feedback - I do agree, I think end goal is definitely a significant increase in structured customisability from users (and plugin developers) of what the UI can do. Keen to avoid the issues we have now where it's essentially a free-for-all for developers to put what they want where, some hierarchy (without being too restrictive) is definitely needed.

What I'd like to do with these experiments is prove out our current thinkings with real world users, e.g. is the 'Details' widget a sensible place for build/SCM info, is it more organised than what we have now, is this the best way to present this information.

Right now, though, this is just an experiment. It’s simple to implement and easy to roll back if it doesn’t work out, but I'm hopeful it's a positive addition and users respond well. Looking to blog about it/share it with the community once it's live for feedback/polls.

janfaracik and others added 22 commits January 9, 2025 16:04

Init

1c71f4c

Update DurationDetail.java

991f787

Sorting out stuff

f4f8ec9

Update Functions.java

701e7a7

Use passed in run

959a43b

Cleanup

4deafbd

Update DetailFactory.java

1a7bd33

Update Functions.java

abf4d00

Make group of() private

73a48c0

Update DetailGroup.java

5d13a62

Tidy up

0da339b

Push

8886cd9

Update Detail.java

6fd6b1b

Update Functions.java

8cdc3a6

Update DetailFactory.java

538ba93

Update DetailFactory.java

c1cbb0d

Update DetailGroup.java

cac4625

Add isApplicable

c649255

Update DetailGroup.java

b4b01ee

Update grid

64babad

Apply suggestions from code review

7f11407

Merge branch 'master' into experimental-details-widget

d6cf74c

janfaracik requested a review from a team January 13, 2025 09:41

janfaracik added web-ui The PR includes WebUI changes which may need special expertise major-rfe For changelog: Major enhancement. Will be highlighted on the top labels Jan 13, 2025

Remove Javadoc implNote

c53e9d5

timja added the needs-security-review Awaiting review by a security team member label Jan 13, 2025

timja requested a review from a team January 13, 2025 09:49

Add getUrl

3647925

daniel-beck reviewed Jan 13, 2025

View reviewed changes

janfaracik added 2 commits January 13, 2025 13:46

Update _cards.scss

cd2d792

Update _cards.scss

0085d2c

timja removed the needs-security-review Awaiting review by a security team member label Jan 13, 2025

janfaracik added 8 commits January 13, 2025 14:49

Update _cards.scss

89d64f0

Update _cards.scss

924683c

Update _cards.scss

bfcbed3

Update _cards.scss

b7dbb88

Update _build.scss

64929b5

Move details to jenkins from hudson

d3ad66e

Replace flippy timestamp with tooltip (with a delay)

a7878e7

Update _cards.scss

cbf4681

Update core/src/main/java/jenkins/model/Detail.java

72e1ab0

Co-authored-by: Tim Jacomb <[email protected]>

janfaracik added 5 commits January 14, 2025 13:13

Drop isApplicable

2e85c62

Update detail.jelly

aff8281

Merge branch 'master' into experimental-details-widget

91c8e48

Update on comments

aac7d48

Merge branch 'master' into experimental-details-widget

d09ffe9

janfaracik marked this pull request as ready for review January 15, 2025 21:12

timja requested review from daniel-beck and a team January 17, 2025 16:32

janfaracik mentioned this pull request Jan 17, 2025

Add GitHub branch and pull request info to the 'Details' widget jenkinsci/github-branch-source-plugin#826

Draft

8 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add experimental 'Details' widget for builds #10147

Add experimental 'Details' widget for builds #10147

janfaracik commented Jan 13, 2025 •

edited by timja

Loading

Submitter checklist

Maintainer checklist

daniel-beck Jan 13, 2025

janfaracik Jan 14, 2025

daniel-beck Jan 13, 2025

daniel-beck Jan 13, 2025

daniel-beck Jan 13, 2025

daniel-beck commented Jan 13, 2025

timja commented Jan 13, 2025

uhafner commented Jan 13, 2025

timja commented Jan 13, 2025

uhafner commented Jan 14, 2025

janfaracik commented Jan 14, 2025

		public static DetailGroup SCM = new DetailGroup(0);

		public static DetailGroup GENERAL = new DetailGroup(Integer.MAX_VALUE);

Add experimental 'Details' widget for builds #10147

Are you sure you want to change the base?

Add experimental 'Details' widget for builds #10147

Conversation

janfaracik commented Jan 13, 2025 • edited by timja Loading

Testing done

Proposed changelog entries

Proposed upgrade guidelines

Submitter checklist

Desired reviewers

Maintainer checklist

daniel-beck Jan 13, 2025

Choose a reason for hiding this comment

janfaracik Jan 14, 2025

Choose a reason for hiding this comment

daniel-beck Jan 13, 2025

Choose a reason for hiding this comment

daniel-beck Jan 13, 2025

Choose a reason for hiding this comment

daniel-beck Jan 13, 2025

Choose a reason for hiding this comment

daniel-beck commented Jan 13, 2025

timja commented Jan 13, 2025

uhafner commented Jan 13, 2025

timja commented Jan 13, 2025

uhafner commented Jan 14, 2025

janfaracik commented Jan 14, 2025

janfaracik commented Jan 13, 2025 •

edited by timja

Loading