Status: Resolved (View Workflow)
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: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.
- is related to
JENKINS-21486 Refuse to load a plugin if dependencies are disabled or outdated
Code changed in jenkins
User: Daniel Beck
Merge pull request #2236 from daniel-beck/
JENKINS-34073 JENKINS-34073 Revert fix for JENKINS-21486
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.
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
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)
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).
Since 2.1, users can enable disabled plugins even if they are dependencies. So FS access is no longer needed.
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).