Jenkins jobs assigned to java web-start slaves.
The jobs in question were all working fine.
The call stack is essentially useless, and points to an exception handler in some Java class without indicating what exactly was attempted.
Unfortunately this occurred just as I was preparing for a holiday. I do not have exact call stack now (I'm on a train).
I fixed the problem by making the script explicitly perform a svn checkout/update rather than the normal method where one provides the URL and credentials in the fields for the "configure" page.
That should be a good indication of where the issue lies.
I really would like some kind of feedback on this issue, even though I will be away for a week. I would like to have the "normal" functionality and am willing to help investigate.
Master and slaves are identical.
I am also having this issue on various machines.
Ian Tait added a comment - 2015-09-24 20:27 I am also having this issue on various machines.
we are facing a similar problem. We are using Jenkins version 1.591, and have two slaves configured. In case the job uses our slave-01, we are getting the NoClassDefFoundError shown below. If I configure the job, to use our slave-02, it works fine. We were not able to find any configuration differences between our slaves.
From what I see Jenkins class is not being propagated to slaves. It may happen if you enable Slave2Master security AFAIK.
Anyway,SubversionSCM:: createDefaultSVNOptions() is misdesigned. It should not access descriptior() on its own. Once it is being called on slave, the method should retrieve the data from master via another remoting call. If the class is serializable, such double propagatiion will work correctly.
Some bits of the issue have been introduced in https://github.com/jenkinsci/subversion-plugin/commit/208f10ba16f8317f64060262fa82477db18be299 , but I think the real cause is even older.
Oleg Nenashev added a comment - 2016-02-16 11:14 From what I see Jenkins class is not being propagated to slaves. It may happen if you enable Slave2Master security AFAIK. Anyway,SubversionSCM:: createDefaultSVNOptions() is misdesigned. It should not access descriptior() on its own. Once it is being called on slave, the method should retrieve the data from master via another remoting call. If the class is serializable, such double propagatiion will work correctly. Some bits of the issue have been introduced in https://github.com/jenkinsci/subversion-plugin/commit/208f10ba16f8317f64060262fa82477db18be299 , but I think the real cause is even older.
Oleg Nenashev thanks for your answer.
The option "Enable Slave → Master Access Control" is not selected in our Jenkins configuration. When it had been selected it would affect all slaves, if I understand it correctly. As we have this problem only with one of our slaves, I don't think that this setting is relevant in our case.
Peter Varga added a comment - 2016-02-16 13:35 Oleg Nenashev thanks for your answer. The option "Enable Slave → Master Access Control" is not selected in our Jenkins configuration. When it had been selected it would affect all slaves, if I understand it correctly. As we have this problem only with one of our slaves, I don't think that this setting is relevant in our case.