Suppose you have:
job("foo") {
parameters {
stringParam("BAR", "default", "This is a chocolate bar")
}
}
How can we abstract BAR out?
def bar(context) {
context.with {
stringParam("BAR", "default", "This is a chocolate bar")
}
}
job("foo") {
parameters {
bar delegate
}
}
This is OK, but if you load this in an IDE, 'stringParam' will have the "unresolved symbol" squiggly. Can we do better? Yes... with another helper function!
def parameters_snippet(@DelegatesTo(BuildParametersContext) c) {
return { context -> context.with c }
}
def bar = parameters_snippet {
stringParam("BAR", "default", "This is a chocolate bar")
}
job("a") {
parameters { bar delegate }
}
Ah! Much better.
I am not completely satisfied though:
1. Is there a way to eliminate any mention of 'delegate' at the call site?! Based on reading through Groovy's docs, it doesn't look like it.
3. Here's another way to skin this cat:
def parameters_snippet(@DelegatesTo(Job) c) {
return { context -> context.with { parameters { c() } } }
}
def bar = parameters_snippet {
stringParam("BAR", "default", "This is a chocolate bar")
}
This sort of solves (2), since it means all you ever need to know is the name of the top-level context (Job), and then you can just write out the path for the configuration you want to set. But let's say I abstract both "bar" and "baz" this way; is it guaranteed that Groovy will always *append* these two parmeters to the parameters block? At least for 'parameters', this happens; but I am nervous that there might be some case where it doesn't;
https://github.com/jenkinsci/job-dsl-plugin/wiki/User-Power-Moves#understanding-configxml-generation---multiple-calls-to-the-same-command claims that in some cases it may override. Am I guaranteed, for commands that take closures, for multiple invocations of the command to append?