[JENKINS-69113] renovate progressBar

[mawinter69]

The progressbar used at various places is replaced by a div/span combination and gets a new styling that is in sync with other ui elements. It is a little bit higher, has rounded corners and some padding, the minwidth is set to 10% so we always have at least a bit to show, it also avoids that the border is not rounded, e.g. when we're at just 2% and the progressbar is only 2px wide.
Animation is now based on css and no longer a gif and can also be enabled via a flag.
The build progress bar shown on run and console views is now updated dynamically including the tooltip.
The progress bar used in progressive rendering is doubled in size to make it more prominent that it is still running (See [JENKINS-72138], this doesn't solve the problem but might lower the chance that people reload the mentioned page because they think nothing happens).
This also fixes JENKINS-68631

After
Build history widget:

Executor widget:

Run view:
Here the progress bar will change over time

Console view with stuck:

Progressive rendering (agent build history) with bigger progress bar:

See JENKINS-69113.

Testing done

Manual testing:

• create job that runs for 1 minute
• trigger job (no previous builds) -> progress bar is at 100% and animated (on executor widgets, run page and console page)
• trigger job (with previous builds) -> progress bar is animated and increases over time

To see stuck jobs

• Create job that does nothing
• run the job several times
• Change job to sleep for 1 minute
• run job -> the progressbar should now be red animated.

Tested for freestyle and pipeline jobs

Proposed changelog entries

• JENKINS-69113, renovate progressBar

Proposed upgrade guidelines

N/A

Submitter checklist

Beta 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

@mention

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

Maintainer checklist

Beta 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).

[janfaracik]

Looking good!

I was looking at doing something similar last year, but never finished it. Here’s the branch if it’s at all helpful - https://github.com/jenkinsci/jenkins/compare/master...janfaracik:jenkins:progress-bar-new?expand=1.

Screen.Recording.2024-01-03.at.13.51.48.mov

A few things -

• I think it’d be best to use the existing colour palette for consistency rather than using the colours from the existing progress bar, e.g. using the accent colour for progress, error colour for errors etc.
• I think there should be separate animations for progress/indeterminate states, e.g. a soft pulse for progress, horizontal translation when indeterminate
• It’s a little chunky at the moment and draws a lot of attention - maybe that’s okay though?

Let me know your thoughts 👍

[NotMyFault]

Looking good!

I was looking at doing something similar last year, but never finished it. Here’s the branch if it’s at all helpful - master...janfaracik:jenkins:progress-bar-new?expand=1 (compare).

Screen.Recording.2024-01-03.at.13.51.48.mov
A few things -

• I think it’d be best to use the existing colour palette for consistency rather than using the colours from the existing progress bar, e.g. using the accent colour for progress, error colour for errors etc.
• I think there should be separate animations for progress/indeterminate states, e.g. a soft pulse for progress, horizontal translation when indeterminate
• It’s a little chunky at the moment and draws a lot of attention - maybe that’s okay though?

Let me know your thoughts 👍

I'm a big fan of your proposed implementation of the progress bars. I agree we should stick with the current color palette for consistency :)

[mawinter69]

The animation is now only used in the widgets when the progress is unknown or is is set via an option.
Using existing color palette now
moved the css to separate file.

[mawinter69]

Should the padding be a bit bigger maybe?
like this:

[NotMyFault]

I'm really fond of the redesign, 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]

Breaks jenkins.branch.NoTriggerBranchPropertyTest#suppressNothing and jenkins.branch.NoTriggerBranchPropertyTest#suppressEvents:

java.lang.AssertionError: 

Expected: is <2>
     but: was <3>
	at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
	at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:6)
	at jenkins.branch.NoTriggerBranchPropertyTest.suppressNothing(NoTriggerBranchPropertyTest.java:135)
	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
	at org.jvnet.hudson.test.JenkinsRule$1.evaluate(JenkinsRule.java:656)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
	at java.base/java.lang.Thread.run(Thread.java:1583)

[mawinter69]

I wonder how this change could cause this error. This change only affect jelly/js files so it is pure UI

[basil]

Are you implying that this PR may not be the cause of the test failures? The tests deterministically fail with this PR and pass when this PR is reverted, so this PR is the (proximate) cause of the test failures.

[jglick]

I also got here via git bisect. NoTriggerBranchPropertyTest runs JenkinsRule.configRoundtrip so it does exercise GUI code.

This PR also causes a failure in the ATH BuildHistoryTest (both test cases) at https://github.com/jenkinsci/acceptance-test-harness/blob/0ac2b663128e2c20bfdcacbf095496bd7c6b43ab/src/main/java/org/jenkinsci/test/acceptance/po/BuildHistory.java#L31.

[mawinter69]

It's definitely happening after configRoundTrip
But I think it is not related to this change.
When I add a 30 sec sleep after the configRoundTrip, then also the current master of branch-api plugin built against 2.426.1 fails.
Isn't there an automatic first run triggered after saving the configuration?

[jglick]

Thanks, I can take a look at whether NoTriggerBranchPropertyTest is just overly sensitive to timing.