I personally rather see removed plugins have labels and jenkins core filters out removed ones, so they can still get security warnings and stuff. But a secondary list of removed plugins would also work and be pretty easy I think (from plugin-site side).

Security warnings and deprecation warnings are already served separately, which allows Jenkins to show these even for plugins no longer distributed, so this doesn't apply.

Note that all the changes to the plugin site needed in my proposal would be to point to a different JSON file. Obviously it would be good to indicate a plugin is no longer being distributed, or we're just replacing one cause for confusion ("Why is this mentioned somewhere but not on the plugin site?") for another ("Why is this listed on the plugin site but not accessible in Jenkins?").

The problem is those instructions are not passed along to the user via the Update Center or pluginManager UI; it's just gone 403 to the user.

If you have it installed, Jenkins will tell you. It's just not available for installation.

https://github.com/jenkins-infra/update-center2/blob/55f6a4370e090b25cf359c0773a60c1939e8253f/resources/deprecations.properties#L129 creates a deprecation notice with a link to the issue. There could be better docs but by the time we did this it had been deprecated in docs for well over a year.

In this case, there's no indication in the Update Center/ pluginManager why it's no longer available AND there's no indication in GitHub there's anything wrong by policy or vulnerability.

Good point. At the time we removed it, I hoped it would be temporary, so didn't add a label that would inform existing users. This is a simple oversight that can easily be addressed with a PR to update-center2.

The banner could be a useful mechanism to warn existing plugin users of the license violation (which may impact their continued use).

As above, we have ways to inform existing users, it's just new users (and that includes renewed users, e.g. in ephemeral Jenkins setups) that have a harder time figuring out what happened. As deprecation metadata is served through the usual means, this is an RFE to whatever the plugin management tool of choice is.

a banner similar to UNAVAILABLE

Possible by iterating over over each entry in deprecations/security warnings and creating placeholders for the plugin IDs, but the code underlying the update center is a bit of a mess, plus we don't have any metadata right now other than plugin ID. Additionally we've had plenty negative feedback to "UNAVAILABLE", indicating it's confusing, so I'm not sure this is a great choice.

TBH with the plugin site showing placeholders for plugins that are no longer being distributed, I'm not sure we need a solution inside Jenkins. I Would hold that off for a bit.

ianw simple tombstone pages have been implemented, e.g. https://plugins.jenkins.io/pmd/ . I suggest to close this issue and in case you have some more ideas for improvements create a new one.

zbynek, this is a great start and does address the specific example given (PMD), although the Search Results for "PMD" still return "not found".

The other scenario given in the comments is for tfs-plugin (INFRA-2751) and liquibase-runner (INFRA-2622)(since restored). These plugins (and I believe a number of others, tho I can't find the reference at the moment) were pulled as a result on license compliance issues. Perhaps oleg_nenashev or danielbeck know where such list resides.

It would helpful if a similar tombstone were back-filled for the other plugins pulled for reasons of deprecation, licensing (as reported by [~halkeye] ), or other known plugin issues.

It would be helpful if the tombstone status was reflected in the https://plugins.jenkins.io/ page / results.

This issue will become more prevalent as I've read many discussions to clean up the plugin repository, eg: (Java 11, commons-digeter, guava) for valid reasons which might cause plugins to be removed.

The focus here should be on "newbie-friendly" user experience. There are many external references and documents which may lead a user to search for a specific plugin on the plugins site. The user should be presented with better guidance than "not found".

Finally, there should be some explanation on Removing plugins from distribution Update-Centre docs regarding implementing a tombstone.

Just to be clear, the issue is fixed. There is no longer a PMD plugin, and its been properly highlited as such. I'm not comfortable with never ending issues though.

The original 403 issue was how nginx was handing empty directories. We've now added support for plugins which are suspended being documented, but the system isn't magic, its only as good as the data that is provided. There's a PR for adding more of the suspended plugins to the update center metadata.

So while I agree there's still need for more things, I think they should be documented as new separate feature requests. Mark has already started to add[ some search aliases|https://github.com/jenkins-infra/plugin-site/blob/master/src/utils/algolia-queries.js#L44-L50]. You could easily submit a PR to add an alias for pmd and warnings? or you could ask Ulli to add PMD to the description of the warnings plugin.

I'm going to mark this ticket as closed because the plugin site bug is fixed, but your absolutely right improvements can be made. Feel free to re-open though if you need, but I recommend PRs or new specific issues on the plugin site github