[JENKINS-75350] Displays plugin health score in Plugin Manager

[alecharp]

See JENKINS-75350.

I'm trying to display the plugin health score within the plugin manager of Jenkins.
This is using jenkins-infra/update-center2#840.

Updates

Available

Installed

Testing done

I ran an instance locally, in development mode, using a classic update-center, one generated from jenkins-infra/update-center2#840 and one where I removed some of the plugins scores.

This allowed me to see that I have the same behaviour with current update-center, that I can display score when all the plugins have one and don't display it when at least one plugin doesn't have one.

Proposed changelog entries

• Display plugin health score from the Plugin Manager

Proposed changelog category

/label major-rfe

Proposed upgrade guidelines

N/A

Submitter checklist

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

Desired reviewers

@daniel-beck @timja @janfaracik

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

Maintainer checklist

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

[mawinter69]

On Plugin site the values are given in % so I would do this here as well

[mawinter69]

Why should no score values be shown when at least on plugin is missing it? Can't we then just show N/A

[daniel-beck]

This needs a corresponding (also conditional) change below

jenkins/core/src/main/resources/hudson/PluginManager/available.jelly

Line 84 in 47ec730

<th>${%Released}</th>

to balance the potential new column.

[daniel-beck]

I suggest you consider adding this information to https://github.com/jenkinsci/jenkins/blob/master/core/src/main/resources/hudson/PluginManager/installed.jelly -- while not as straightforward, it would help admins decide continued use of already installed plugins, especially on longer-lived instances.

(If too scope-creepy, could also be added later.)

[alecharp]

On Plugin site the values are given in % so I would do this here as well

Yes definitively. For now, I'm not "happy" with how the value are shown but couldn't think of a good way to do it. I opened the pull request so that we can discuss about it, see if we want plane values or using a card..

Why should no score values be shown when at least on plugin is missing it? Can't we then just show N/A

@mawinter69 when a instance has a custom plugin for example. Some company have developed in-house plugins and those won't have any scores. I didn't think about the N/A, I felt not having the scores at all would be fair to those plugins.

This needs a corresponding (also conditional) change below to balance the potential new column.

As the column definition is done in the Jelly file but I couldn't find a way to test either or not we would have the health score in it, we could have a "grey" cell when there is no health score to display.

I suggest you consider adding this information to https://github.com/jenkinsci/jenkins/blob/master/core/src/main/resources/hudson/PluginManager/installed.jelly

It is my intention to have it there and in updates as well. This is, as this stage, not a complete pull request, that's why it is in draft ;)

[timja]

Potentially a chip pattern sort of thing? https://m2.material.io/components/chips

There's this but might be a bit much: https://weekly.ci.jenkins.io/design-library/banner/

[janfaracik]

Potentially a chip pattern sort of thing? https://m2.material.io/components/chips

I was experimenting with something like this for suggested plugins:

Maybe a progress bar around the outside could work too?

[alecharp]

Maybe a progress bar around the outside could work too?

around the outside? What do you mean? I was afraid that using a progress bar would be too much of a distraction on the page.

[alecharp]

Here's what I changed:

• using "N/A" when there is no score
• don't remove all scores if one is missing
• adds a column header on available page
• scores are link to the plugin-site health score page of the plugin.

screenshot

[alecharp]

The installed plugins are instances of PluginWrapper which are built from the files. This will require a bit more redesign. I'm still looking into it.

[alecharp]

with 3370920, we have the score displayed on all installed, updates and available page. I've updated the pull request description with screenshots.

[cristina-pizzagalli]

@alecharp In my opinion, having a progress bar in this context would be confusing. If all users could realistically achieve a health score of 100/100, it would make sense—but in many cases, perfect isn't attainable. Seeing an always-unfinished progress bar could feel discouraging. Similarly, displaying a percentage (%) might be frustrating for users.

A simple and effective alternative, commonly used with health scores, is color-coding the number using a red/orange/green scheme. I've attached an example from HubSpot, where they pair this approach with chip-style badges labeled Healthy, Neutral, and At-Risk. These text-based labels ensure accessibility for color-blind users while avoiding the negative connotation of an "incomplete" score.

[alecharp]

In my opinion, having a progress bar in this context would be confusing

I totally agree.

Similarly, displaying a percentage (%) might be frustrating for users

well, showing 87 or 87 / 100 or 87% is the same to me, but we can stick to 87.

These text-based labels ensure accessibility for color-blind users while avoiding the negative connotation of an "incomplete" score

Yes, this is what we did on the plugin-site search page. However, I wanted those colours to be based on statistics on all the scores. Like, having red for anything below the 1st quartile, orange between 1st and 3rd quartile and green for anything over 3rd quartile. But we don't have those statistics in the update-center and I don't think we should / could have them there, what do you think @daniel-beck ?

[alecharp]

@cristina-pizzagalli I made some changes. Not yet ready to be pushed because I cannot change the colour based on the health score for now. But here what I can look like:

The green would only be for scores > 90, orange for 50-90 and red for the rest. We can discuss the thresholds but know that currently:

• first quartile: 61,
• average score: 77,
• median score: 85,
• 3rd quartile: 96

[mawinter69]

Ideally we have the same thresholds as we use on plugins.jenkins.io
green > 80
60 < orange <= 80
red <= 60
Would be confusing to users if the colors differ.

[alecharp]

Ideally we have the same thresholds as we use on plugins.jenkins.io

I agree. I just wanted to note that static thresholds might not be great. But I'm more than ok to have the same as plugin-site.

[alecharp]

Ok, I failed to see how I can have different CSS class applied to the link based on the health score. I tried creating an helper, even a partial but I either couldn't write it correctly or use it correctly. @janfaracik if you could give me some pointer, that would be great.

[alecharp]

I just updated the screenshots with recent code modifications.

[mawinter69]

The pics are not correct, what you have under updates is actually the installed page and vice versa.
For the installed page you put the health score between the button to disable and the button to uninstall. I think it would be better to have the health score as the last column.

[alecharp]

The pics are not correct, what you have under updates is actually the installed page and vice versa.

Thanks. Fixed.

For the installed page you put the health score between the button to disable and the button to uninstall. I think it would be better to have the health score as the last column.

I didn't want to disrupt users from finding the uninstalled button on the last cell of the row. But I'm not opposed to that.

[mawinter69]

I was thinking of putting it to the right as it is also the last column on the updates and available pages. We could also put it to the left of the disable button. Just not between those buttons I think.
Let's see what other think about this.

[alecharp]

Example of installed page with health score in last column

screenshot