I have the following script:

public class DSLHelpers {
    public static void violations(out, job, typeName, minNum, maxNum, 
unstableNum, filenamePattern = null) {
        job.configure { project ->
            def violationsConfig = project / publishers / 
'hudson.plugins.violations.ViolationsPublisher' / 'config'

*            /* these are the lines relevant to the discussion */*
*            def typeConfigsNode = violationsConfig / typeConfigs*
*            def typeEntry = typeConfigsNode / entry*
*            /* --- */*

            typeEntry / string(typeName)
            def typeConfig = typeEntry / 
'hudson.plugins.violations.TypeConfig'
            typeConfig / type(typeName)
            typeConfig / min(minNum)
            typeConfig / max(maxNum)
            typeConfig / unstable(unstableNum)
            typeConfig / usePattern(filenamePattern ? "true" : "false")
            typeConfig / pattern(filenamePattern)
            // out << project
        }
    }
}

job {
    name "Tools-jshint-dsl"
    DSLHelpers.violations(out, delegate, "jslint", 10, 11, 10, 
"test-reports/*.xml")
}

Running a job with this DSL script succeeds and has the following output:

Existing Templates: 
New Templates: 
Unreferenced Templates: 
Adding jobs: 
Existing jobs: GeneratedJob{jobName='Tools-jshint-dsl', templateName=none}
Removing jobs: 
Finished: SUCCESS


However, the /job/Tools-jshint-dsl 404's and there's nothing on the 
filesystem in ~jenkins/jobs/ either.

Here's the tricky part though: removing the 'typeConfigs' node and making 
typeEntry 
= violationsConfig / entry results in success *and* the expected generated 
job. Using a different name ('foo') in place of typeConfigs also results in 
the expected XML (.//config/foo/entry), and placing a 'typeConfigs' node 
elsewhere in the document hierarchy also results in invalid XML. (Of 
course, all of these yield an incorrect document, they're merely test cases 
to figure out what the heck is going on).

When the document is written to stdout (using, I assume, Node.toString()), 
typeConfigs does appear, so it's would appear that it's correctly added to 
the Node object. It's possible there's something wrong with Node's 
serialization but that seems unlikely.

All of this leads me to believe that there's something incompatible with an 
XML node named 'typeConfigs' when being used with Job-DSL.

Does anyone have any ideas about what the cause may be, or any suggestions 
as to what else I might investigate?

Reply via email to