Jenkins war > 2.190.1 plugin bundling issue

[ftclausen]

NOTE: Originally reported as JENKINS-59722 but they regard this use case as unsupported. So reporting here to see if there is anything that can be done.

When starting up the Jenkins war file, with at least 2.190.1 or greater, as part of generating the Job XML the following error is shown:

java.io.IOException: Jenkins Git plugin version 3.12.1 failed to load.
 - SCM API Plugin version 2.4.1 is older than required. To fix, install version 2.6.3 or later.
        at hudson.PluginWrapper.resolvePluginDependencies(PluginWrapper.java:922)
        at hudson.PluginManager$2$1$1.run(PluginManager.java:545)
        at org.jvnet.hudson.reactor.TaskGraphBuilder$TaskImpl.run(TaskGraphBuilder.java:169)
        at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:296)
        at jenkins.model.Jenkins$5.runTask(Jenkins.java:1118)
        at org.jvnet.hudson.reactor.Reactor$2.run(Reactor.java:214)
        at org.jvnet.hudson.reactor.Reactor$Node.run(Reactor.java:117)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at java.lang.Thread.run(Thread.java:748)

After some investigation it appears that scm-api is bundled in the war file at WEB-INF/detached-plugins/scm-api.hpi. If we include a newer scm-api in the jenkinsPlugin Gradle dependency configuration then it makes no difference

What we have been seeing is that, if any plugin specified in "jenkinsPlugins" depends on a plugin bundled in the Jenkins core war file then it'll use that even if a newer one is specified in "jenkinsPlugins". In the case of "Git" depending on "scm-api", it uses the bundled one that is too old. Again, even if we specify a newer scm-api in the "jenkinsPlugin" configuration.

I have created a small example project that illustrates this issue:

https://github.com/ftclausen/JENKINS-59722

See README.md for how to trigger.

[robinverduijn]

@mnonnenmacher any ideas on this issue?

[robinverduijn]

With a newer Jenkins 2.190.2 dependency, another similar error pops up, possibly caused by a similar version mismatch:

  10.797 [id=1] SEVERE  h.i.i.InstallUncaughtExceptionHandler$DefaultUncaughtExceptionHandler#uncaughtException: A thread (main/1) died unexpectedly due to an uncaught exception, this may leave your Jenkins in a bad way and is usually indicative of a bug in the code.
groovy.lang.MissingMethodException: No signature of method: javaposse.jobdsl.plugin.structs.DescribableListContext.git() is applicable for argument types: (learnsaas.captain.script$_run_closure1$_closure2$_closure6$_closure7$_closure8) values: [learnsaas.captain.script$_run_closure1$_closure2$_closure6$_closure7$_closure8@4507f4b8]
Possible solutions: wait(), wait(long), is(java.lang.Object), with(groovy.lang.Closure), grep(), any()
        at jdk.internal.reflect.GeneratedConstructorAccessor46.newInstance(Unknown Source)
        at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
        at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
        at org.codehaus.groovy.reflection.CachedConstructor.invoke(CachedConstructor.java:83)
        at org.codehaus.groovy.runtime.callsite.ConstructorSite$ConstructorSiteNoUnwrapNoCoerce.callConstructor(ConstructorSite.java:105)
        at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallConstructor(CallSiteArray.java:59)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:238)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:266)
        at javaposse.jobdsl.plugin.structs.DescribableListContext.methodMissing(DescribableListContext.groovy:65)

[robinverduijn]

I wonder if updating https://github.com/heremaps/gradle-jenkins-jobdsl-plugin/blob/master/gradle.properties to use Jenkins 2.190.2 (and plugin versions to match) would be enough to fix this?

[robinverduijn]

I found that updating the versions in gradle.properties did not help with this issue, but was able to confirm that deep inside the jenkins-test-harness code, something is responsible for loading 2 different versions of a given plugin if an older one was included in the jenkins-war detached-plugins folder.

Filed https://issues.jenkins-ci.org/browse/JENKINS-60295 for that, and hoping that there is something that can be done either in Jenkins core (the jenkins-war build) or the jenkins-test-harness. That said, if there is a fix which can be made in gradle-jenkins-jobdsl-plugin, that would be great as well. My current hack is to disable loading of detached-plugins entirely in the jenkins-test-harness by specifying a custom PluginManager.

My hackish workaround with which we are currently running locally can be found at https://github.com/heremaps/gradle-jenkins-jobdsl-plugin/compare/3.7.0...robinverduijn:fix-jenkins-detached-plugins