How to convert freestyle "Current build parameters" setting to pipeline?

Using Jenkins
1

I have a parameterized freestyle project that uses the Parameterized Trigger plugin with the “Current build parameters” setting to pass all of the job’s current parameters to any triggered jobs. I have converted this freestyle project to a declarative pipeline, and I want to enable this “Current build parameters” behavior in the new pipeline so all jobs triggered using the build command share the same parameters as the parent pipeline. However, I can’t really find any pipeline examples that utilize the “Current build parameters” option. What is the correct way to set up a pipeline so it makes all triggered jobs use the same set of parameters?

2

I am not sure if there is any automation to magically pass all of the current Pipeline build parameters to any and all jobs triggered by it. But you can iterate over the parameters and construct new data from it on your own.

Let’s say you have a pipeline with Choice parameter FOO, of values 1,2,3 Boolean parameter BAR unchecked by default, and Password parameter BAZ empty by default, that just prints whatever is passed to it:

params.each { k, v ->
    println "${k.class} / ${v.class}"
    println "$k / $v"
}

If I trigger this pipeline manually with FOO selected to 2, BAR unchecked and BAZ changed to 12345, I get

16:48:45  class java.lang.String / class java.lang.Boolean
16:48:46  BAR / false
16:48:46  class java.lang.String / class java.lang.String
16:48:46  FOO / 2
16:48:46  class java.lang.String / class hudson.util.Secret
16:48:46  BAZ / 12345

Now let’s have a second pipeline with String parameters BAR, XXX that would trigger the first one with everything it has plus some additional parameters:

build(
    job: 'sandbox/tmp-params-child',
    parameters: params.collect { k, v ->
        string(name: k, value: v)
    } + [
        string(name: 'FOO', value: '3')
    ]
)

Note that if you’re using Declarative pipelines, you will probably need to do this wrapped inside a script { } step.

Despite different types in the original pipeline, here I pass everything as string()s. Most of the parameters often used in Jenkins jobs may be considered “derivatives of a string”, and usually are constructed from strings. When I run it with BAR=true, XXX=ccc, Jenkins will notify me about a type mismatch (only for BAR though, somehow – but a couple years back we didn’t have even that), and complete the build just fine:

16:58:58  Scheduling project: sandbox » tmp-params-child
16:58:58  The parameter 'BAR' did not have the type expected by sandbox » tmp-params-child. Converting to Boolean Parameter.
16:59:05  Starting building: sandbox » tmp-params-child #6
16:59:07  Build sandbox » tmp-params-child #6 completed: SUCCESS

Looking in the triggered job’s build, we can see that the types are right and it have actually accepted the extra parameter:

16:59:05  class java.lang.String / class java.lang.Boolean
16:59:06  BAR / true
16:59:06  class java.lang.String / class java.lang.String
16:59:06  FOO / 3
16:59:06  class java.lang.String / class java.lang.String
16:59:06  XXX / ccc
16:59:07  class java.lang.String / class hudson.util.Secret
16:59:07  BAZ /

If I were to run it with some invalid value for FOO, Jenkins would complain about it without actually triggering the second job:

16:54:59  Scheduling project: sandbox » tmp-params-child
16:54:59  [Pipeline] End of Pipeline
16:54:59  ERROR: Invalid parameter value: (StringParameterValue) FOO='true'

If your pipelines operate on more complex parameters, and you’d have to maintain the types already on the calling side, you would probably need to make a utility function (and consider putting it into a shared library, so it could be reused between jobs) that would look at the type of your inputs – via instanceof for example – and construct elements of different types for parameters list.

...
parameters: params.collect { k, v -> parameterize(k, v) }
...
def parameterize(name, value) {
  if (value instanceof String) {
    return string(name: name, value: value)
  } else if ...
1 Like
3

This seems to work. However, I did get tripped up by the parameters for the Jenkins Subversion Plugin. The “List Subversion Tags” parameter provided by that plugin will generate parameter entries in params, but they’re always NULL. You have to instead reference environment variables created by the plugin.

Thanks for the assistance.