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

[alecharp]

See JENKINS-75350.

Display the plugin health score within the Jenkins plugin manager.
This is using:

• Incorporate plugin health score in JSON metadata jenkins-infra/update-center2#840.

Plugin Updates

Available Plugins

Installed Plugins

Testing done

I ran an instance locally, in development mode, using a classic update-center, one generated from update center PR 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.

[timja]

What about?

A score evaluating the health of a plugin, using metrics such as actively maintained, recommended repository configuration applied and documentation provided. Learn more

cc @MarkEWaite / @kmartens27

[kmartens27]

What about?

A score evaluating the health of a plugin, using metrics such as actively maintained, recommended repository configuration applied and documentation provided. Learn more

I think this is an alright description. I would adjust some of the phrasing here so that it reads more of a quantity vs yes/no (maintenance activity vs active maintenance) since there are multiple factors for the scores noted. However, that's just me being nit-picky and if it's too wordy then it's not necessary. Also just something to add in the security aspect of the score.

Something like:
A score evaluating the health of a plugin, using metrics such as maintenance activity, completeness of the recommended repository configuration, types of documentation provided, and whether there are outstanding security issues. Learn more

[alecharp]

That is a bit long but if we all agree on the description, here what it can look like:

[timja]

FWIW I prefer the short version and Learn more doesn't need three dots imo. (not a blocker)

[kmartens27]

Right, I forgot it was supposed to be the tooltip. I would go with the shorter version in this case.

[alecharp]

Noted. Implementing this and trying to find how to reference other properties to not copy paste the message.

[alecharp]

I sadly had to copy the message in different places, not being able to find how to reference the message present for another page.

[timja]

Test failing is likely related

[alecharp]

Test failing is likely related

yes. I'm trying to resolve it but it's not running locally, I have to rely on CI.

[timja]

Test failing is likely related

yes. I'm trying to resolve it but it's not running locally, I have to rely on CI.

If the issue is in your IDE (lots of tests fail that way). Then run it directly with maven on the CLI

[alecharp]

If the issue is in your IDE (lots of tests fail that way). Then run it directly with maven on the CLI

I tried both. Each time, I have

[ERROR] Errors: 
[ERROR]   PluginManagerInstalledGUITest.test_enable_disable_uninstall » Reactor java.lang.NullPointerException: Cannot invoke "java.net.URL.openConnection()" because "url" is null

Maybe because I tried to only run this specific test.

[uhafner]

Can we extract such a column as a jelly file in core so that we have only one percentage visualisation in Jenkins? A percentage column might be useful for other plugins as well and would provide a consistent UI for all such usages. [...] it would be worth to create a consistent UI.

I based the "design" based on feedback from UX Sig and Cristina inputs in #10351 (comment). I'm open to change things but I heard the "perfect is not the target" argument and that's why we have also the colour green matching anything above 90.

My point is that we should not create such a badge as private thing of the update manager code, this should be moved to our core UI elements (design library). There we can add more generalizations like colors, etc.
Otherwise other plugins will start with copy pasting this code into their use cases making it hard to keep it consistent...

See also jenkinsci/design-library-plugin#42

[alecharp]

I tried to create the score layout. But even for this pull request, it's not totally useful as the available page is using an handlebar template.

[krisstern]

LGTM

[alecharp]

Should we move forward on this or is there anything I need to fix on it?

[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!