Rewrite the build history widget

[janfaracik]

This PR implements the changes discussed https://community.jenkins.io/t/revamped-build-history-widget/10944. In essence it's a rewrite/redesign of the build history widget. The goal is to be cleaner and simpler, whilst still retaining existing functionality and density.

Before

After

What's changed

• The JS has been rewritten and does away with a lot of the complicated layout logic in favour of CSS flex/grid.
• A new card component has been added (with the intention of replacing the existing widget component) that supports inline actions
• Builds now group by date, keeping the UI simpler/easier to read
• RSS feed has been moved to a dropdown, rather than a fixed button row
• Build overflow menus are now always present on the right of the link

What doesn't work

• ✅ Pagination controls are always visible at the moment
• ✅ The list doesn't auto refresh at the moment
• ✅ Items with long names/lots of actions don't scale very well

Testing done

• See Rewrite the build history widget #9148 (comment) for a view of the scenarios tested
  • Normal scenarios work as expected (e.g. short build names, one or two badges)
  • Queued items look as expected
  • Items with plain text/HTML descriptions work as expected
  • Items with long names/lots of badges wrap as expected

Proposed changelog entries

• Update the design of the build history widget.

Proposed upgrade guidelines

N/A

Submitter checklist

Preview Give feedback

1. The Jira issue, if it exists, is well-described.
2. 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.
3. There is automated testing or an explanation as to why this change has no tests.
4. New public classes, fields, and methods are annotated with @Restricted or have @since TODO Javadocs, as appropriate.
5. New deprecations are annotated with @Deprecated(since = "TODO") or @Deprecated(forRemoval = true, since = "TODO"), if applicable.
6. 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).
7. For dependency updates, there are links to external changelogs and, if possible, full differentials.
8. For new APIs and extension points, there is a link to at least one consumer.

Desired reviewers

@jenkinsci/sig-ux

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

Maintainer checklist

Preview Give feedback

1. There are at least two (2) approvals for the pull request and no outstanding requests for change.
2. Conversations in the pull request are over, or it is explicit that a reviewer is not blocking the change.
3. Changelog entries in the pull request title and/or Proposed changelog entries are accurate, human-readable, and in the imperative mood.
4. Proper changelog labels are set so that the changelog can be generated automatically.
5. 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).
6. 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).

[timja]

can you add before screenshots too please

[mawinter69]

How does this look when a build has a display name?
How does it look when a build has many badges?
Just an example how this looks currently:

[janfaracik]

How does this look when a build has a display name? How does it look when a build has many badges? Just an example how this looks currently:

It's okay but could be better - I think moving the badges onto a new row when its incredibly long would improve it.

[mawinter69]

What made the previous implementation so big was the logic to find a suitable way to arrange all the things. See #9122 for my PR that changed they calculation to be more efficient.

[github-actions]

Please take a moment and address the merge conflicts of your pull request. Thanks!

[janfaracik]

Getting ReferenceError: "fetch" is not defined. (http://localhost:42617/jenkins/static/8bd93229/jsbundles/pages/project/builds-card.js#52) in tests - have you experienced this before @timja?

[timja]

Getting ReferenceError: "fetch" is not defined. (http://localhost:42617/jenkins/static/8bd93229/jsbundles/pages/project/builds-card.js#52) in tests - have you experienced this before @timja?

I see the issue, PR incoming

[timja]

jenkinsci/jenkins-test-harness#753

[daniel-beck]

starting somewhere

I'd like to see at minimum a plan for widespread implementation of this, a proof of concept of sorts. At this point, for me there are too many unanswered questions. How will this work with bread crumbs? List views that contain regularly 3+ such menus on a single line? Consecutive links (Job Name (v) #123 (v))? Links in build logs?

While in isolation this improves the situation for a single control, increasing the inconsistency across the entire UI, without a plan how to get all of Jenkins to adapt, makes it overall net negative for the entire Jenkins UI, especially if we're considering the expectations for the plugin ecosystem to adapt over the long term.

If retaining the flexible-size model-link isn't feasible (although the ones in the build log also don't move surrounding text), could the icon/design be changed to be more closely to a (hovered) model-link?

[janfaracik]

starting somewhere

I'd like to see at minimum a plan for widespread implementation of this, a proof of concept of sorts. At this point, for me there are too many unanswered questions. How will this work with bread crumbs? List views that contain regularly 3+ such menus on a single line? Consecutive links (Job Name (v) #123 (v))? Links in build logs?

For sure. There'll be some refinement of the https://jenkins-redesign.vercel.app soon and I'll be sure to include something in that to address the various areas where model-link is used.

If retaining the flexible-size model-link isn't feasible (although the ones in the build log also don't move surrounding text), could the icon/design be changed to be more closely to a (hovered) model-link?

Can do, yes. Like so?

[daniel-beck]

Can do, yes. Like so?

Much better, thanks!

[timja]

/label ready-for-merge

---

This PR is now ready for merge, after ~24 hours, we will merge it if there's no negative feedback.

Thanks!

[basil]

This changes causes org.jenkinsci.plugins.authorizeproject.strategy.SystemAuthorizationStrategyTest and hudson.plugins.copyartifact.CopyArtifactWorkflowTest to start failing in PCT.

While the failures are relatively straightforward (a lack of fetch method presumably due to an out-of-date test harness, which could be fixed by releasing versions with the latest plugin parent POM), introducing new PCT failures will negatively impact other critical projects and is not something that we can afford.

Since I have detected this before the weekly release has shipped and before the new failures are introduced, I am tentatively planning to revert this on Monday before the next weekly ships. I would rather not do this, since I am pleased with this PR, but as mentioned above the reasoning is to avoid impacting other projects. The amount of effort required to prepare for this change is not terribly high (updating plugin parent POMs in two plugins and adopting the releases in BOM), but it is effort nonetheless and it needs to be done as part of the due diligence of accepting this change.

[janfaracik]

This changes causes org.jenkinsci.plugins.authorizeproject.strategy.SystemAuthorizationStrategyTest and hudson.plugins.copyartifact.CopyArtifactWorkflowTest to start failing in PCT.

While the failures are relatively straightforward (a lack of fetch method presumably due to an out-of-date test harness, which could be fixed by releasing versions with the latest plugin parent POM), introducing new PCT failures will negatively impact other critical projects and is not something that we can afford.

Since I have detected this before the weekly release has shipped and before the new failures are introduced, I am tentatively planning to revert this on Monday before the next weekly ships. I would rather not do this, since I am pleased with this PR, but as mentioned above the reasoning is to avoid impacting other projects. The amount of effort required to prepare for this change is not terribly high (updating plugin parent POMs in two plugins and adopting the releases in BOM), but it is effort nonetheless and it needs to be done as part of the due diligence of accepting this change.

Hey @basil, thanks for raising this!

Happy to fix this (and eager to avoid reverting too) - I haven't worked with PCT before, is there a test output you could link to/is there any guidance around working with it so I can fix it?

[basil]

@janfaracik The problem can be reproduced in authorize-project-plugin outside of PCT. First, run mvn clean install -Pquick-build in Jenkins core (tip of trunk, with the latest unreleased changes), then run the test in authorize-project-plugin with that version of core by running mvn clean verify -Dtest=org.jenkinsci.plugins.authorizeproject.strategy.SpecificUsersAuthorizationStrategyTest#testConfigurationAuthentication -Djenkins.version=2.463-SNAPSHOT (where the last version number is what you compiled in the previous command). It will fail with the same "fetch is not defined" error as PCT. The same should apply to copyartifact-plugin.

In this case at least, it looks like the root cause is that src/test/java/org/jenkinsci/plugins/authorizeproject/testutil/AuthorizeProjectJenkinsRule.java is returning a new WebClient without the fetch polyfill enabled. I confirmed this change fixes it:

diff --git a/src/test/java/org/jenkinsci/plugins/authorizeproject/testutil/AuthorizeProjectJenkinsRule.java b/src/test/java/org/jenkinsci/plugins/authorizeproject/testutil/AuthorizeProjectJenkinsRule.java
index ab30f3e..e63c8f8 100644
--- a/src/test/java/org/jenkinsci/plugins/authorizeproject/testutil/AuthorizeProjectJenkinsRule.java
+++ b/src/test/java/org/jenkinsci/plugins/authorizeproject/testutil/AuthorizeProjectJenkinsRule.java
@@ -56,7 +56,7 @@ public class AuthorizeProjectJenkinsRule extends JenkinsRule {
 
     @Override
     public WebClient createWebClient() {
-        return new WebClient() {
+        WebClient webClient = new WebClient() {
             private static final long serialVersionUID = 3389654318647204218L;
 
             @Override
@@ -68,6 +68,8 @@ public class AuthorizeProjectJenkinsRule extends JenkinsRule {
                 super.throwFailingHttpStatusCodeExceptionIfNecessary(webResponse);
             }
         };
+        webClient.getOptions().setFetchPolyfillEnabled(true);
+        return webClient;
     }
 
     public void before() throws Throwable {

Likely a similar thing needs to be done in copyartifact-plugin. My point, as mentioned in the preceding comment, is not that preparing plugins in this case is particularly difficult, just that it needs to be done in advance of releasing this PR in a core weekly in order to avoid impacting other projects.

[janfaracik]

@janfaracik The problem can be reproduced in authorize-project-plugin outside of PCT. First, run mvn clean install -Pquick-build in Jenkins core (tip of trunk, with the latest unreleased changes), then run the test in authorize-project-plugin with that version of core by running mvn clean verify -Dtest=org.jenkinsci.plugins.authorizeproject.strategy.SpecificUsersAuthorizationStrategyTest#testConfigurationAuthentication -Djenkins.version=2.463-SNAPSHOT (where the last version number is what you compiled in the previous command). It will fail with the same "fetch is not defined" error as PCT. The same should apply to copyartifact-plugin.

In this case at least, it looks like the root cause is that src/test/java/org/jenkinsci/plugins/authorizeproject/testutil/AuthorizeProjectJenkinsRule.java is returning a new WebClient without the fetch polyfill enabled. I confirmed this change fixes it:

diff --git a/src/test/java/org/jenkinsci/plugins/authorizeproject/testutil/AuthorizeProjectJenkinsRule.java b/src/test/java/org/jenkinsci/plugins/authorizeproject/testutil/AuthorizeProjectJenkinsRule.java
index ab30f3e..e63c8f8 100644
--- a/src/test/java/org/jenkinsci/plugins/authorizeproject/testutil/AuthorizeProjectJenkinsRule.java
+++ b/src/test/java/org/jenkinsci/plugins/authorizeproject/testutil/AuthorizeProjectJenkinsRule.java
@@ -56,7 +56,7 @@ public class AuthorizeProjectJenkinsRule extends JenkinsRule {
 
     @Override
     public WebClient createWebClient() {
-        return new WebClient() {
+        WebClient webClient = new WebClient() {
             private static final long serialVersionUID = 3389654318647204218L;
 
             @Override
@@ -68,6 +68,8 @@ public class AuthorizeProjectJenkinsRule extends JenkinsRule {
                 super.throwFailingHttpStatusCodeExceptionIfNecessary(webResponse);
             }
         };
+        webClient.getOptions().setFetchPolyfillEnabled(true);
+        return webClient;
     }
 
     public void before() throws Throwable {

Likely a similar thing needs to be done in copyartifact-plugin. My point, as mentioned in the preceding comment, is not that preparing plugins in this case is particularly difficult, just that it needs to be done in advance of releasing this PR in a core weekly in order to avoid impacting other projects.

Big thanks for this - opened merge requests for both plugins.

[MarkEWaite]

opened merge requests for both plugins.

Requests have been merged and released for both plugins. Pull requests were:

• Fix WebClient missing polyfill copyartifact-plugin#232
• Fix WebClient missing polyfill authorize-project-plugin#236

BOM pull requests submitted by dependabot to include in a new release of the plugin bill of materials:

• Bump org.jenkins-ci.plugins:copyartifact from 722.v0662a_9b_e22a_c to 746.vd2a_674fb_4f6f in /bom-weekly bom#3307
• Bump org.jenkins-ci.plugins:authorize-project from 1.7.1 to 1.7.2 in /bom-weekly bom#3306

I plan to deliver a new release of the plugin bill of materials within the next 8 hours. A release was just delivered successfully, so I don't expect any issue with the new release.

[MarkEWaite]

Plugin bill of materials https://github.com/jenkinsci/bom/releases/tag/3135.v6d6c1f6b_3572 includes those two plugin releases.

[hankzhao-zp]

I found that when displaying a very long http link, it looks a bit bad

[timja]

I found that when displaying a very long http link, it looks a bit bad

can you raise an issue on https://issues.jenkins.io please?

[hankzhao-zp]

I found that when displaying a very long http link, it looks a bit bad

can you raise an issue on https://issues.jenkins.io please?

No problem, it's done
https://issues.jenkins.io/browse/JENKINS-73437

[daniel-beck]

I filed JENKINS-73613 for this, seems like poor UX.