-
Bug
-
Resolution: Unresolved
-
Major
Hit it multiple times while running PCT for JEP-200. Some tests retrieve Plugin instances from Jenkins instance using the following commands:
- getPluginManager().getPlugin("git") - e.g. GitHub plugin
- Jenkins.getInstance().getPlugin("ownership") - e.g. Ownership plugin. In this case the plugin's production logic fails since it's code accesses the plugin (to be fixed though)
With recent Jenkins cores / JTH both methods ALWAYS return null, and it breaks tests
[JENKINS-48885] JenkinsRule always returns null in getPluginManager().getPlugin() on new core versions
Any update or workaround (downgrade jenkins core for tests?) for this? This kind of limits the usage of the jenkins testing harness 
Gyula Varga
added a comment - - edited Any update or workaround (downgrade jenkins core for tests?) for this? This kind of limits the usage of the jenkins testing harness
mac_ Sorry, I got reassigned to another task. No ETA. I will unassign myself
I was able to get around this by defining my own PluginManager. I found that the loading of the plugins was being done by a "shortName" , so github-api instead of github-api-1.4.3.jpi .I had a set of gradle tasks that would write the plugins I wanted to a resource directory and an index file. The UnitTestSupportingPluginManager had this snippet:
URL index = getClass().getResource("/test-dependencies/index");
When debugging through it, I noticed that my set of plugins was doing:
copyBundledPlugin(url, line + ".jpi");
Where URL was /some/path/on/my/machine/github-api-4.3.jpi and line was github-api-4.3
The plugin manager would try to find "github-api" and either load an old version (which caused other plugins to not load) or flat out not find things.
I documented a bit more on this PR (which I think linked to this issue): https://github.com/mkobit/jenkins-pipeline-shared-libraries-gradle-plugin/issues/65#issuecomment-668193573
Workaround suggested by anemortalkid is a feasible solution. A more sustainable approach (IMHO) is to generate the manifest file for maven dependencies, and then to make Jenkins test Harness to read it. Recently I hit a similar issue in Jenkinsfile Runner. Not surprising since it largely inherits the JTH plugin manager.. I will try to fix it in both codebases.
References:
- https://github.com/jenkinsci/jenkinsfile-runner/issues/389
- https://github.com/jenkinsci/jenkinsfile-runner/issues/390
Please distinguish carefully between PluginWrapper PluginManager.getPlugin(String), which is perfectly normal, and Plugin Jenkins.getPlugin(String), which is almost never what you want: https://github.com/jenkinsci/jenkins/pull/1940#issuecomment-161304577
Right. This approach would address PluginWrapper PluginManager.getPlugin(String). This is a good start, I'd guess.
It might get us closed to supporting Plugin Jenkins.getPlugin(String), but I am not too concerned about it in 2020
Job DSL is another plugin that makes use of these APIs