How to use DslScriptLoader.runDslEngine when migrating tests to job-dsl-core 1.40

[Christian Rasp]

Hi,

we are currently trying to migrate to job-dsl-core 1.40, but get stuck while updating our tests due to the changes for JENKINS-30348.

Here is one example of what we do

@Shared List<File> jobDslFiles = JobHelper.getAllJobDslFiles()
final JobManagement jm = JobHelper.createJobParent().getJm()

def 'test basics for #script'() {
    setup:
    URL scriptURL = new File(script.getPath()).toURI().toURL()
    ScriptRequest scriptRequest = new ScriptRequest(script.name, null, scriptURL)

    expect:
    DslScriptLoader.runDslEngineForParent(scriptRequest, jm).getReferencedJobs().each { Job job ->
        with(job.node) {
            !logRotator.text().isEmpty()
            !description.text().isEmpty()

        }
    }

    where:
    script << jobDslFiles
}

Basically we check specific config nodes to be existent or to have the right configruation value. How can we keep this up using DslScriptLoader.runDslEngine(scriptRequest, jm)?

One thing I realized is that we could switch the JobManagement (we use new FileJobManagement(new File("target/generated-configs"))) to MemoryJobManagement in order to get access to the savedConfigs but then we would have to parse it back to xml first. That doesn't seem to be the right approach, or am I wrong?

[Daniel Spilker]

What's the source of the problem? Why is the update to 1.40 causing problems?

Daniel

--
You received this message because you are subscribed to the Google Groups "job-dsl-plugin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to job-dsl-plugi...@googlegroups.com.
To post to this group, send email to job-dsl...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/job-dsl-plugin/c1c170c6-8c3f-45f4-aa2a-e4321bcca2e5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Matt Sheehan]

I think because it used to return JobParent but now it returns GeneratedItems so there's no longer access to Job.

[Daniel Spilker]

Ah, right. Sorry, I forgot about that.

The problem with job.node was that it executes the configure blocks each time it get's called. And those configure blocks can reference classes from the "additional classpath". After the fix of the classloader leak, it's no longer possible to call job.node outside of DslScriptLoader.runDslEngineForParent. I thought about referencing the root node from GeneratedJob, but a node may contain any object as value. And those values may come from classes from the closed classloader, so that's not good either. Using the string serialization of the XML is a save way to transport the config.

You have to refer to JobManagement to get the config. You can read the XML back in using either

Node node = new XmlParser().parse(new StringReader(xmlString))

or

Node node = new XmlParser().parse(xmlFile)

Daniel

To view this discussion on the web visit https://groups.google.com/d/msgid/job-dsl-plugin/CAKZH%3Ddbtm6BEH8UK9tfztmeNb%2BqW7_kG442NH%3Dx1g0SXP%2B%2BeBA%40mail.gmail.com.

[Christian Rasp]

Thank you for your help, this works like a charm. Btw, combined with MemoryJobManagement it helped us a lot to get rid of some side effects while testing. Introducing that was a great idea!