I doubt that recompiling will help. The problem is with VirtualMachineLauncher. It implements ComputerLauncher, but it does not contain the requested fields as described. But I think it does not block VirtualMachineSlaveComputer and VirtualMachineSlave from inheriting UI of the standard launcher as you pointed in the code. It may be a defect in the core, because there are other similar reports. Obviously the best way would be to just take ownership of the plugin and facelift it to support Work directories... but it should not break.
Could you please create a separate ticket to LibVirt plugin? I will forward it to my colleagues who may be interested to investigate it I've been trying to do that, but I'm new to Maven, and it's not clear to me > yet how to force the build to use a more current Jenkins release. > Unfortunately libvirt Plugin uses an old Parent POM (1.580). In Parent POM 2.x we have added a support of "jenkins.version" property which allows building custom Jenkins versions. So you could use Parent POM 3.6 and build for Jenkins 1.625.3 or 2.107.1 depending on your needs. But the plugin needs an update to do that. On Monday, March 26, 2018 at 11:39:38 PM UTC+2, Glenn Burkhardt wrote: > > So, how do we get a copy of the libvirt plugin compiled against the > current Jenkins core code? It looks like the libvirt plugin was compiled > against jenkins-core-1.625.3.jar, and the JNLPLauncher class didn't contain > a "RemotingWorkDirSettings workDirSettings" field at that time. It might > be that simply re-compiling against a more current version of core Jenkins > code will fix it. > > I've been trying to do that, but I'm new to Maven, and it's not clear to > me yet how to force the build to use a more current Jenkins release. > > Thanks! > > On Saturday, March 24, 2018 at 9:42:57 AM UTC-4, Oleg Nenashev wrote: >> >> The ticket has been created to a wrong component, so it has never been >> triaged. I will the components. >> From what I see the Libvirt plugin inherits standard Agent's UI, so the >> new Jenkins core tries to generate JNLP with workDir. >> >> Also, how does one debug a jelly script like "slave-agent.jnlp.jelly"? I >>> can't find it anywhere in my deployed Jenkins system. >>> >> >> Please see >> https://wiki.jenkins.io/display/JENKINS/Figuring+out+URL+binding+of+Stapler >> >> >> On Friday, March 23, 2018 at 6:46:03 PM UTC+1, Glenn Burkhardt wrote: >>> >>> Jenkins ver. 2.108 <https://jenkins.io/>, Libvirt Slaves plugin 1.8.5 >>> >>> I'm trying to get a slave windows client running in a VM under 'libvirt' >>> to start properly. I've identified the problem to be the same as described >>> in https://issues.jenkins-ci.org/browse/JENKINS-47834. >>> The problem is that the "slave-agent.jnlp" generated by Jenkins omits >>> the argument for "-workDir" and "-remoteDir". >>> >>> I've been trying to understand how the "slave-agent.jnlp.jelly" script >>> generates the file, and I suspect that the script and the Libvirt plugin >>> are out of sync. In particular, there's a reference in the script to >>> "launcher.workDirSettings.workDirPath". But the VirtualMachineLauncher >>> class defined in the plugin doesn't contain a 'workDirSettings' field. >>> The delegate does, and the debugger indicates that it's a JNLPLauncher >>> class. >>> >>> I see a line in the script that says: >>> >>> <j:set var="launcher" value="${it.delegatedLauncher}"/> >>> >>> Does that somehow get mapped to the delegate field in >>> the VirtualMachineSlaveComputer class, which is what the 'it' argument >>> passed to EncryptedSlaveAgentJnlpFile turns out to be. >>> >>> Also, how does one debug a jelly script like "slave-agent.jnlp.jelly"? >>> I can't find it anywhere in my deployed Jenkins system. >>> >>> Thanks. >>> >> -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/80faf09f-5e02-4a07-b026-528dac2f27a5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
