Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-34073

Plugin dependency fix (JENKINS-21486) not visible enough

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Critical Critical
    • core

      This is about https://github.com/jenkinsci/jenkins/pull/2172

      As I wrote in https://github.com/jenkinsci/jenkins/pull/2001, which is essentially its predecessor:

      I expect that this will result in a perceived regression in a large number of installations with broken configurations: While previously, only some (possibly unused) part of plugin functionality was unavailable due to class loading issues when that was actually used, now Jenkins will fail to load the entire plugin. Problems like the one described in the issue I expect to be a pretty rare and severe case of dependency problem.

      Therefore I have real concerns about this change without a corresponding change on the UI. I still have nightmares about 1.524, which fixed something similar.

      Of course, before PR 2172 even made it into a released version of Jenkins, this happened in #jenkins:

      2016-04-06T13:45:27+0200 <karrboloaded> After installing 1.657, the conditional build step plugin is uninstalled and it's failing to reinstall
      2016-04-06T13:45:57+0200 <karrboloaded> Is this a known thing or should I log it somewhere?
      2016-04-06T13:47:36+0200 <karrboloaded> The stack trace contains "java.io.IOException: Dependency is disabled, but I've verified that the dependencies are not disabled
      2016-04-06T13:53:41+0200 <@danielbeck> karrboloaded Could you post the full stach trace somewhere?
      2016-04-06T13:54:39+0200 <@danielbeck> Also, 1.657? Hasn't been released.
      2016-04-06T13:55:20+0200 <karrboloaded> I'm installing via "brew install jenkins --HEAD"
      2016-04-06T13:56:06+0200 <karrboloaded> Without --HEAD it installs 1.390 or something like that
      2016-04-06T13:56:50+0200 <karrboloaded> It's 1.657-SNAPSHOT, to be precise.
      2016-04-06T13:57:56+0200 <karrboloaded> How can i get the full stack trace? I'm looking in updateCenter and it snips it
      2016-04-06T14:00:49+0200 <@danielbeck> That is positively insane.
      2016-04-06T14:00:53+0200 <@danielbeck> https://github.com/Homebrew/homebrew-core/blob/master/Formula/jenkins.rb
      2016-04-06T14:01:14+0200 <@danielbeck> This is definitely not what a package manager should do.
      2016-04-06T14:01:41+0200 <@danielbeck> FWIW the current formula downloads 1.655, which is a recent reelase. If you get something older than that, update your formulas.
      2016-04-06T14:02:06+0200 <karrboloaded> OK, will do
      2016-04-06T14:02:08+0200 <@danielbeck> For the stack trace, try the logs at the /log/all URL
      2016-04-06T14:02:35+0200 <@danielbeck> karrboloaded Would appreciate if you could help me investigate this.
      2016-04-06T14:02:43+0200 <@danielbeck> Otherwise there may be a real issue in the next release.
      2016-04-06T14:04:11+0200 <karrboloaded> I've put the first bit of the output from starting jenkins at pastebin.com/Mz9Piqaw
      2016-04-06T14:04:55+0200 <karrboloaded> I'll get the rest from /log/all now
      2016-04-06T14:05:28+0200 <@danielbeck> karrboloaded Could you provide the output of "ls -lA JENKINS_HOME/plugins" (substitute JENKINS_HOME for wherever that is)
      2016-04-06T14:06:10+0200 <@danielbeck> Probably $HOME/.jenkins
      2016-04-06T14:11:32+0200 <karrboloaded> It's at pastebin.com/6xhnxPdf
      2016-04-06T14:12:56+0200 <@danielbeck> karrboloaded Awesome, thanks. Could you also post the output on the /systemInfo URL? There's a table towards the bottom about what plugins are installed in which versions, and whether they're pinned/enabled.
      2016-04-06T14:13:20+0200 <@danielbeck> karrboloaded FYI we found the first bug already that caused the dependency to not be specified.
      2016-04-06T14:15:56+0200 <karrboloaded> Awesome, glad I could help
      2016-04-06T14:16:10+0200 <karrboloaded> Just the plugins table?
      2016-04-06T14:19:15+0200 <@danielbeck> karrboloaded Yes, that's enough
      2016-04-06T14:20:54+0200 <karrboloaded> I pasted the table HTML at pastebin.com/7cRd6Gte
      2016-04-06T14:24:13+0200 <karrboloaded> Or at jsfiddle.net/wu6kLr13 so you can render it right in your browser
      2016-04-06T14:27:24+0200 <@danielbeck> karrboloaded Awesome. I'll take a look. Are you a regular in this channe;?
      2016-04-06T14:31:57+0200 <karrboloaded> No @danielbeck, I just figured it's the best way to get support
      2016-04-06T14:32:50+0200 <karrboloaded> I don't know the how jenkins issue logging works, so I came here
      2016-04-06T14:33:20+0200 <@danielbeck> karrboloaded Did you manually install plugins or always use the plugin manager for that?
      2016-04-06T14:33:33+0200 <karrboloaded> I might become a regular, this visit has really payed off
      2016-04-06T14:34:04+0200 <karrboloaded> I always use the plugin manager, but I tried to manually install it to try to fix the issue
      2016-04-06T14:34:44+0200 <@danielbeck> karrboloaded All of "WARNING: Failed to load com.cloudbees.hudson.plugins.folder.properties.AuthorizationMatrixProperty$DescriptorImpl" are false positive. it's a bug in matrix-auth. If you want the warning to go away, install Folders Plugin.
      2016-04-06T14:35:25+0200 <karrboloaded> Thanks
      2016-04-06T14:35:34+0200 <@danielbeck> karrboloaded Regarding conditional-buildstep…
      2016-04-06T14:35:48+0200 <karrboloaded> I've reverted to 1.655 and I'm not having any issues now
      2016-04-06T14:36:08+0200 <@danielbeck> karrboloaded Yeah but your configuration is still invalid
      2016-04-06T14:36:10+0200 <@danielbeck>
      2016-04-06T14:36:17+0200 <@danielbeck> Older versions were just more tolerating
      2016-04-06T14:36:23+0200 <karrboloaded> TIL homebrew needs to be updated... I thought the versioning was automatic
      2016-04-06T14:36:34+0200 <@danielbeck> maven-plugin is a dependency of conditional-buildstep, and is disabled on your instance.
      2016-04-06T14:36:50+0200 <@danielbeck> So rm maven-plugin.jpi.disabled and restart.
      2016-04-06T14:37:14+0200 <@danielbeck> (Another bug – sigh – prevents you from enabling disabled dependencies on the UI)
      2016-04-06T14:37:44+0200 <@danielbeck> But I kicked the dev for that a few minutes ago so that also should be fixed in the next release.
      2016-04-06T14:38:58+0200 <karrboloaded> Will do. Thanks so much for the help
      2016-04-06T14:39:46+0200 <@danielbeck> karrboloaded You're welcome. Thanks for coming here and telling us about the problem!

      We can't just have log messages and a plugin manager that doesn't even show the failed plugin here. While JENKINS-21486 needs to be addressed, the current solution isn't good enough.

          [JENKINS-34073] Plugin dependency fix (JENKINS-21486) not visible enough

          Daniel Beck added a comment -

          It's too late to write and test an adequate UI for 2.0 RC, this should be rolled back and addressed properly in a subsequent release (2.1 would be fine for me).

          Daniel Beck added a comment - It's too late to write and test an adequate UI for 2.0 RC, this should be rolled back and addressed properly in a subsequent release (2.1 would be fine for me).

          Code changed in jenkins
          User: Daniel Beck
          Path:
          changelog.html
          core/src/main/java/hudson/PluginManager.java
          core/src/main/java/hudson/PluginWrapper.java
          test/src/test/java/hudson/PluginManagerTest.java
          test/src/test/java/hudson/PluginManagerUtil.java
          test/src/test/java/hudson/PluginWrapperTest.java
          test/src/test/resources/plugins/dependee-0.0.2.hpi
          test/src/test/resources/plugins/depender-0.0.2.hpi
          test/src/test/resources/plugins/mandatory-depender-0.0.2.hpi
          http://jenkins-ci.org/commit/jenkins/1e338d3565c8c58d2556f344a7c34a3b3ab18ca3
          Log:
          Merge pull request #2236 from daniel-beck/JENKINS-34073

          JENKINS-34073 Revert fix for JENKINS-21486

          Compare: https://github.com/jenkinsci/jenkins/compare/25340e033b5d...1e338d3565c8

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Daniel Beck Path: changelog.html core/src/main/java/hudson/PluginManager.java core/src/main/java/hudson/PluginWrapper.java test/src/test/java/hudson/PluginManagerTest.java test/src/test/java/hudson/PluginManagerUtil.java test/src/test/java/hudson/PluginWrapperTest.java test/src/test/resources/plugins/dependee-0.0.2.hpi test/src/test/resources/plugins/depender-0.0.2.hpi test/src/test/resources/plugins/mandatory-depender-0.0.2.hpi http://jenkins-ci.org/commit/jenkins/1e338d3565c8c58d2556f344a7c34a3b3ab18ca3 Log: Merge pull request #2236 from daniel-beck/ JENKINS-34073 JENKINS-34073 Revert fix for JENKINS-21486 Compare: https://github.com/jenkinsci/jenkins/compare/25340e033b5d...1e338d3565c8

          R. Tyler Croy added a comment -

          If I'm understanding this correctly, the only way a user has to correct the plugin dependency issue is to touch files on the Jenkins master's file system correct?

          So the problem is two-pronged:

          1. When the plugin dependency error detection code triggers it doesn't show the user any visible feedback that their Jenkins is in a broken state, it simply disables the plugin entirely. This could be interpreted by the user as functionality "disappearing"
          2. The user has no "supported" means of rectifying the situation outside of manipulating special files on the master file system.

          Correct?

          R. Tyler Croy added a comment - If I'm understanding this correctly, the only way a user has to correct the plugin dependency issue is to touch files on the Jenkins master's file system correct? So the problem is two-pronged: When the plugin dependency error detection code triggers it doesn't show the user any visible feedback that their Jenkins is in a broken state, it simply disables the plugin entirely. This could be interpreted by the user as functionality "disappearing" The user has no "supported" means of rectifying the situation outside of manipulating special files on the master file system. Correct?

          Keith Zantow added a comment - - edited

          Right, at least in this situation where plugins are disabled automatically, it should be made very loud and visible:

          • printed to the logs with any exceptions of course
          • display a banner to users with rights to fix it which links them to the plugin manager
          • plugin manager displays very visibly plugins with these issues, disabled plugins in error, etc.
          • able to fix disabled plugins this through the plugin manager, or if unable to, given direct instruction how

          Keith Zantow added a comment - - edited Right, at least in this situation where plugins are disabled automatically, it should be made very loud and visible: printed to the logs with any exceptions of course display a banner to users with rights to fix it which links them to the plugin manager plugin manager displays very visibly plugins with these issues, disabled plugins in error, etc. able to fix disabled plugins this through the plugin manager, or if unable to, given direct instruction how

          rtyler AFAIU yes, but for me it already what is happening in many cases (The ones of JENKINS-21486)
          it often arrives that because a plugin is disable or in the wrong version all depend plugins don't load and are broken
          In the best case if they are just disabled we can use the UI to reenable them (but you need to have a look at logs to understand what/why) and if it is version issues it depends if you can rollback the change or update to the latest version compatible with your instance.

          I know that kohsuke loves the idea that Jenkins always starts even if plugins are ~ broken. Myself I think more and more that it is a big issue, putting the instance in a unstable state, and especially because there is no real visibility of the issue. For all plugins loading issues we should correctly warn the administrator and put in standby the server to be sure that nothing will be altered with the crappy setup. Or we should fail fast and thus we just don't start (but we loose the ability to use the plugins manager to try to fix the issue)

          Arnaud Héritier added a comment - rtyler AFAIU yes, but for me it already what is happening in many cases (The ones of JENKINS-21486 ) it often arrives that because a plugin is disable or in the wrong version all depend plugins don't load and are broken In the best case if they are just disabled we can use the UI to reenable them (but you need to have a look at logs to understand what/why) and if it is version issues it depends if you can rollback the change or update to the latest version compatible with your instance. I know that kohsuke loves the idea that Jenkins always starts even if plugins are ~ broken. Myself I think more and more that it is a big issue, putting the instance in a unstable state, and especially because there is no real visibility of the issue. For all plugins loading issues we should correctly warn the administrator and put in standby the server to be sure that nothing will be altered with the crappy setup. Or we should fail fast and thus we just don't start (but we loose the ability to use the plugins manager to try to fix the issue)

          Daniel Beck added a comment -

          Jenkins could come up in 'preparing to shut down' mode if any plugin fails to load, in addition to everything Keith mentions. WDYT?

          Daniel Beck added a comment - Jenkins could come up in 'preparing to shut down' mode if any plugin fails to load, in addition to everything Keith mentions. WDYT?

          There is https://github.com/jenkinsci/jenkins/pull/2234 to give the user a warm up about the problem (item #2 from keith).

          Vincent Latombe added a comment - There is https://github.com/jenkinsci/jenkins/pull/2234 to give the user a warm up about the problem (item #2 from keith).

          Daniel Beck added a comment -

          Since 2.1, users can enable disabled plugins even if they are dependencies. So FS access is no longer needed.

          Daniel Beck added a comment - Since 2.1, users can enable disabled plugins even if they are dependencies. So FS access is no longer needed.

          Daniel Beck added a comment -

          Fixed in a new JENKINS-21486 PR merged towards 2.16.

          Daniel Beck added a comment - Fixed in a new JENKINS-21486 PR merged towards 2.16.

            Unassigned Unassigned
            danielbeck Daniel Beck
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: