-
Bug
-
Resolution: Fixed
-
Major
-
None
Steps
- Running Jenkins version 2.426.3
- Upgraded Build Blocker Plugin from 1.7.9 to 165.v5ecb_fb_f61520
- Jobs failed to run: pending - Exception evaluating if the gueue can run the task
- From jenkins.log
2024-05-09 16:15:39.749+0000 [id=115] WARNING hudson.model.Queue#getCauseOfBlockageForItem: Exception evaluating if the queue can run the task 'Sample-Build-Misc' java.lang.ClassNotFoundException: com.cloudbees.hudson.plugins.folder.AbstractFolderPropertyDescriptor Caused: java.lang.NoClassDefFoundError: com/cloudbees/hudson/plugins/folder/AbstractFolderPropertyDescriptor at hudson.plugins.buildblocker.BuildBlockerQueueTaskDispatcher.getBuildBlockerProperty(BuildBlockerQueueTaskDispatcher.java:220) at hudson.plugins.buildblocker.BuildBlockerQueueTaskDispatcher.canRun(BuildBlockerQueueTaskDispatcher.java:95) at hudson.model.Queue.getCauseOfBlockageForItem(Queue.java:1209) at hudson.model.Queue.maintain(Queue.java:1544) at hudson.model.Queue$1.call(Queue.java:332) at hudson.model.Queue$1.call(Queue.java:329) at jenkins.util.AtmostOneTaskExecutor$1.call(AtmostOneTaskExecutor.java:109) at jenkins.util.AtmostOneTaskExecutor$1.call(AtmostOneTaskExecutor.java:99) at jenkins.security.ImpersonatingExecutorService$2.call(ImpersonatingExecutorService.java:80) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at hudson.remoting.AtmostOneThreadExecutor$Worker.run(AtmostOneThreadExecutor.java:121) at java.base/java.lang.Thread.run(Thread.java:840)
Workaround/Fix
- Installed Folders plugin (6.858.v898218f3609d) and it works
- is caused by
-
JENKINS-72588 Support for folder properties
-
- Resolved
-
- links to
[JENKINS-73119] Build Blocker plugin 165.v5ecb_fb_f61520 has undocumented dependency on Folders
| Link |
New:
This issue is caused by |
| Link |
Original:
This issue is caused by |
| Link |
New:
This issue is caused by |
I'm able to duplicate the bug. It seems that the cloudbees-folder dependency was added as an optional dependency but some of the code is written in such a way that it is a required dependency.
I confirmed that once I add the cloudbees-folder plugin to the installed set of plugins, the failure is resolved.
The cloudbees-folder plugin is widely used. It seems to me that the best choice is to make it a required dependency rather than an optional dependency. If it must remain optional, then the code needs to be reworked to not fail when the cloudbees-folder plugin is not installed.
| Remote Link | New: This issue links to "PR-25 - make folders plugin dependency required, not optional (Web Link)" [ 29647 ] |
| Status | Original: Open [ 1 ] | New: In Progress [ 3 ] |
| Remote Link | New: This issue links to "PR-26 catch the class not found exception so that folders plugin is not a required dependency (Web Link)" [ 29648 ] |
I've submitted two different proposed fixes. One continues to make the folders plugin optional and seems to better match the intentions of jonesbusy. It is PR-26.
The other makes the folders plugin dependency mandatory It is PR-25. I prefer PR-26 since I think it better fits the original intention, but I offer both.
Hello mdorotich.
I am sorry for the problem caused here.
We added the folder plugin as dependency for feature JENKINS-72588
To be honest cloudbees-folder is one of the most popular plugins and AFAIR one that installed by default (though you can still opt out during the installation). Still i should have considered that adding a dependency would cause some installation to fail during a update. That is my fault and i apologize.
Having said that, we have rolled this feature for a couple of weeks now and i don't think we can roll it back.
I have updated the release notes to explicitly specify that and at least not catch other administrators by surprise.
Since installing the cloudbees-folder plugin solves the problem is it ok by you to resolve this ticket?