-
Type:
Bug
-
Status: Open (View Workflow)
-
Priority:
Major
-
Resolution: Unresolved
-
Component/s: jenkins-test-harness
-
Labels:None
-
Similar Issues:
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
Any update or workaround (downgrade jenkins core for tests?) for this? This kind of limits the usage of the jenkins testing harness 
Gyula Varga 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
Job DSL is another plugin that makes use of these APIs