I have a pipeline job named buildall which looks like this:
pipeline {
stages {
stage(\"job1\") {
build job: \"job1\"
If you don't care about the parameter types, this approach does not require disabling the Groovy Sandbox - it simply assumes that all parameters can be treated as a string (won't work for "File", for example):
def myparams = params.collect{
string(name: it.key, value: it.value)
}
build job: 'downstream-job', parameters: myparams
It wouldn't be too hard to expand the logic to handle predefined non-string parameter types, but I agree that this should not be necessary. A better approach would be to expose parameters in the format required by the build() DSL closure, including type specifics that are currently not visible via the "params" global variable, or perhaps to add a boolean, eg:
// I wish:
build job: 'downstream-job', includeMyParameters: true, parameters: anyExtras
You can pass all your pipeline parameters with this :
def params=[]
env.getEnvironment().each{ k, v ->
params.add(string(name:"${k}", value:"${v}"))
}
def slaveJob = build job: 'BuildJob', parameters:params
The following seems to work (I haven't tested it extensively though):
pipeline {
agent any
parameters {
string(name: 'PARAM1', description: 'Param 1?')
string(name: 'PARAM2', description: 'Param 2?')
}
stages {
stage('Example') {
steps {
echo "${params}"
script {
def myparams = currentBuild.rawBuild.getAction(ParametersAction).getParameters()
build job: 'downstream-pipeline-with-params', parameters: myparams
}
}
}
}
}
Drawback: to access rawBuild and getAction you have to disable the Groove sandbox or approve these signatures in Jenkins under Manage Jenkins > In-process Script Approval. This dialog will show you that you might introduced a security vulnerability. So it depends on your environment if you want to take this risk or not.