Build Flow Plugin (pre-release 0.11): Change in SCM behavior?
I'm using a custom built version of the plugin (using the code from this PR: https://github.com/jenkinsci/build-flow-plugin/pull/40). As you can see from the commit history, this is based on the unreleased 0.11 version. In my further exploration of this plugin (and the new version I had built) I realized the build flow job no longer performs SCM operations, which I was previously depending on for providing information (primarily git hash) to the triggered builds. You can see my script here: https://gist.github.com/mikedougherty/7227911 After some investigation I found this commit: https://github.com/jenkinsci/build-flow-plugin/commit/444097d which clearly shows that the plugin was intentionally changed to remove SCM operation. However, now I'm unable to provide the required information to the triggered builds. I'm not 100% clear on why this behavior was changed. Aside from my particular issue it seems to specialize the plugin even further away from what I know as 'standard' jenkins build capabilities. I must admit I struggled at first with the inability to add a pre-step before performing the flow script. At a higher level, I don't understand why this is a separate job type instead of a possible build step to be added to (e.g.) a free-form project. I'd appreciate any insight into the purpose of this change. Any info about the design of the plugin would be helpful aid my understanding as well. For now I'm afraid I'll have to use 0.10 with the customized retry() function. thanks! -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Job-DSL: 'typeConfigs' XML node silently fails?
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?
>>
>>
Job-DSL: 'typeConfigs' XML node silently fails?
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?
