Uploaded image for project: 'Jenkins Website'
  1. Jenkins Website
  2. WEBSITE-764

Deprecated plugin handling - UX

    XMLWordPrintable

Details

    Description

      Not sure if this is a case of someone not following Deprecating or removing a Plugin or that's just the user experience ...

      See StackOveflow question: pmd plugin is not available in jenkins for context.

      User looking for "PMD plugin.
      Search in Plugins site returns two plugins: Violations and Report Info. User obviously knows it exists but can't find it.
      Checking GitHub (if you know the repo, you find jenkinsci/pmd-plugin exists. It is tagged as "Deprecated", repo is "Archived".

      If you click on the link in GitHub, back to plugins site (plugins.jenkins.io/pmd/), you are presented with "403 Forbidden (nginx/1.17.7)".

      From a user experience perspective, if you assume the plugin exists, from prior knowledge or external referral, you are left confused.

      Attachments

        Activity

          danielbeck Daniel Beck added a comment -

          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?").

          danielbeck Daniel Beck added a comment - 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?").
          danielbeck Daniel Beck added a comment -

          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.

          danielbeck Daniel Beck added a comment - 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 Zbynek Konecny added a comment - 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.
          ianw Ian Williams added a comment -

          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.

           

           

          ianw Ian Williams added a comment - 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.    
          halkeye Gavin Mogan added a comment -

          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

          halkeye Gavin Mogan added a comment - 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

          People

            Unassigned Unassigned
            ianw Ian Williams
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: