We have some flows to verify compatibility of Jenkins LTS versions with plugins. E.g. https://github.com/jenkinsci/acceptance-test-harness/
But Libvirt Agent plugin is not included there AFAICT. So far it is not confirmed whether it is a plugin defect or regression in the core. I assume the first options taking my rusty knowledge about this part of the codebase. But the issue needs a triage to say for sure. BR, Oleg On Tuesday, March 27, 2018 at 2:22:49 PM UTC+2, Glenn Burkhardt wrote: > > I've created an issue: https://issues.jenkins-ci.org/browse/JENKINS-50427 > > Thanks for your attention. > > I understand the attractiveness of plugins, but using them does raise an > issue of maintenance and compatibility. Perhaps the plugins should be > included in the build of Jenkins so problems can be identified. And also, > once an incompatibility has been recognized, that the documentation in the > wiki could include the latest version of Jenkins with which the plugin is > known to work. In order to reduce the burden on the core maintainers, once > an incompatibility is recognized, the plugin could be dropped from the > build until interested parties bring it up to rev. > > > On Tuesday, March 27, 2018 at 4:15:13 AM UTC-4, Oleg Nenashev wrote: >> >> 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/0b11864d-2130-4cd7-b0ba-23d88dee61a9%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
