I've sent my reply to the job-dsl-plugin group, which I must have missed when searching for the right place to start this thread ;)
For anyone that might be following along at home, the new thread is over here: https://groups.google.com/forum/?fromgroups=#!topic/job-dsl-plugin/wajQbppRsX0 On Sunday, January 13, 2013 4:58:55 PM UTC-8, Justin Ryan wrote: > > Node.toString isn't an exact representation of what is saved. Under the > covers, each dsl method and configure method just queue's up the closures > that need to be run to generate the xml. They are then played back once the > whole DSL has been run through. This all happens in Job.getXml(), so you'll > want to call that to see exactly is going to be saved. Though you can also > turn up the logging in Jenkins to see the output right before it is saved. > It's logged at the FINE level from javaposse.jobdsl.dsl.DslScriptLoader. If > you want direct access to the node, you run executeWithXmlActions(project), > that's what we use in the unit tests heavily > > Now, concerning your example, I like how you're calling a utility method > inside the job block. I don't see any reason why it wouldn't work. I hope > don't mind but I added a unit test to the code base to check for this: > > > https://github.com/jenkinsci/job-dsl-plugin/commit/88e6d1e74e2c172231c7e5292735708b7da31c92 > > The structure maps to what I would think you're creating. I'm not familiar > with the Violation Publisher plugin. Maybe you could send the > job-dsl-plugin google group what you think the XML should be. Take a look > at the unit test above, does it fit with what you're trying to do? > > (BTW, the job-dsl-plugin has its own google group. But I'll make sure to > monitor this one too now) > > On Thursday, January 10, 2013 12:13:07 PM UTC-8, Mike Dougherty wrote: >> >> 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? >> >>
