Jenkins Pipeline Parameters
External
- https://wiki.jenkins.io/display/JENKINS/Parameterized+Build
- https://jenkins.io/doc/book/pipeline/jenkinsfile/#handling-parameters
- https://devopscube.com/declarative-pipeline-parameters/
Internal
Overview
A parameter is a way to configure a pipeline. If you think of a pipeline as a function, then a parameter is the function's argument. When a parameterized build is in the queue, an attempt to start another build of the same project will only succeed if the parameter values are different, or if the "Execute concurrent builds if necessary" option is enabled.
Each parameter has a name and a value, which depends on the parameter type. The parameter name is case-sensitive. A default value and a description can be specified when the parameter is declared. Each parameter should have a unique name within a pipeline definition. Spaces are not permitted in parameter names.
A pipeline that exposes parameters enables parameterized builds and its UI will offer the choice to "Build with Parameters":
Parameters can be declared in the pipeline's Jenkinsfile (preferred), in the UI when the pipeline is created, or in both. For a discussion on parameter declaration, see Parameter Declaration below. Alternatively, if the pipeline is not parameterized, the UI will expose a "Build Now" options, which does not give a choice of parameters.
The parameters of a certain pipeline instance can be accessed at runtime from Jenkinsfile via this.params, which is a read-only Map that maintains parameter name - parameter value association. params is a pipeline global variable. Additional documentation on the params global variable is available at http://<jenkins-instance-url>/pipeline-syntax/globals#params.
For more details on accessing parameters see Accessing Parameters below. For more details about the data structures associated with a pipeline at runtime see:
Parameter Declaration
The preferred way to define pipeline parameters is to declare them in Jenkinsfile. It is also possible to declare them in the pipeline UI, when the pipeline is defined.
If different parameters are declared in UI and Jenkinsfile, the build will be unstable for the first run, when a union of the parameters declared in the UI and Jenkinsfile will be available to the pipeline. After the build finishes successfully, the Jenkinsfile parameter declaration is used as authoritative source of parameters, and their definitions will overwrite the parameters originally defined in the UI, so if "Build with Parameters" is used after the first run, only the Jenkinsfile-declared parameters show up in the UI.
If your build uses a Jenkinsfile that declares parameters, it is NOT a good idea to declare parameters in the UI. Always use the Jenkinsfile as the authoritative source of parameter definitions. When creating the pipeline, do not specify any parameters in the UI, just use "Build Now" to run it once giving Jenkinsfile a chance to be parsed and loaded, and the Jenkinsfile parameters will be available in the UI during the next run.
Jenkinsfile Parameters
A parameter is declared in the pipeline's Jenkinsfile using a different syntax depending on whether the pipeline is declarative or scripted.
Scripted Pipeline Parameter Declaration
Parameters can be declared a scripted pipeline Jenkinsfile using the syntax shown below:
properties([
parameters([
string(name: 'color', defaultValue: 'blue', description: 'The build\'s color'),
...
])
])
For a multi-line description, use this syntax:
properties([
parameters([
string(name: 'color', defaultValue: 'blue', description: """
This is a
multi-line
description
""".stripIndent())
])
])
For a full list of parameter types that can be added see Parameter Types below.
Declarative Pipeline Paramenter Declaration
Declarative pipelines support parameters by default, with the parameters directive.
Parameter Definition Update Cycle
If a parameter is added, removed or modified in Jenkinsfile, which is then checked into repository, the change will not immediately reflect in the "Build with Parameters" UI. To see the change reflected in the UI, initiate a build with the old parameters, or without any parameters, if the pipeline was just declared, and stop it as soon as the Jenkinsfile is loaded and parsed from the repository. This is a "UI refresh" build. At that point, the change in parameters should reflect in "Build with Parameters" UI.
Note that even if the newly introduced parameter is not available in the UI, it will be available to the script during the "UI refresh" build, carrying the default value as declared in the Jenkinsfile parameter section.
UI Parameters
The parameters can be declared in the UI when the pipeline is defined by checking the "This project is parameterized" box in the General settings tab. This will give access to an interface that allows adding individual parameters, turning the build into a parameterized build. For a full list of parameter types that can be added see Parameter Types below.
⚠️ As mentioned in the Parameter Declaration section above, if your build uses a Jenkinsfile that declares parameters, do not use UI-declared parameters, always rely on the parameters declared in Jenkinsfile.
Parameter Types
Jenkins comes with a set of pre-defined parameter types. Plugins may add new parameter types.
String Parameter
Scripted pipeline syntax:
properties([
parameters([
string(name: 'color', defaultValue: 'blue', description: 'The build color')
])
])
Multi-Line String Parameter
A String parameter that allows newline characters. Scripted pipeline syntax:
TODO
Choice Parameter
A pre-defined set of strings from which a user can pick a value. Scripted pipeline syntax:
properties([
parameters([
choice(name: 'size', choices: ['S', 'M', 'L'], description: 'Size choice (S/M/L)')
])
File Parameter
The full path to a file on the filesystem. Scripted pipeline syntax: TODO
Credentials
A pre-defined Jenkins credential. Scripted pipeline syntax: TODO
Password
Similar to the Credentials type, but allows passing a plain text parameter specific to the job or pipeline. Scripted pipeline syntax: TODO
Boolean
properties([
parameters([
booleanParam(name: 'coffee-flavored', defaultValue: true, description: 'something')
])
Run
An absolute URL to a single run of another job. Scripted pipeline syntax: TODO
Input Parameter
Custom Parameters
TODO: https://wiki.jenkins.io/display/jenkins/parameterized+build
Setting Parameter Values
If parameters are defined in Jenkinsfile, defaults can be set there using the defaultValue: '...' syntax. Those defaults will reflect in the UI after a build cycle, as described in the Parameter Definition Update Cycle section.
"Build with Parameters" gives the user the option to specify values for each defined parameter, before initiating a build. If the user choses not to change anything, the build will start with parameters carrying their "Default Value". A new value specified in the UI will override the default specified in Jenkinsfile. If the build is started automatically, the "Default Value" is used, unless the build triggering function provides the corresponding values, as follows:
build(
job: "IntegrationTesting",
parameters: [
string(name: 'branch', value: serverSha),
string(name: 'branchName', value: branch)
] + artifacts.keySet().sort().collect({ name ->
echo "name: ${name}, value: ${artifacts[name]['artifact']}"
string(name: name, value: artifacts[name]['artifact'])
}),
quietPeriod: 0,
wait: true,
propagate: true
)
Accessing Parameters
The Map containing the build's parameters can be accessed at runtime from the Jenkinsfile with:
this.params
The existence of a parameter can be checked with:
print "exists: " + this.params.containsKey(paramName)
If the parameter exists, its value can be accessed with:
def paramName = "color"
print "parameter value: " + this.params.get(paramName)
or with:
print "parameter value: " + this.params.color
If the parameter does not exist in the map, both examples will print "parameter value: null".
The getOrDefault() can supply a default value:
if (params.getOrDefault('BOOLEAN_PARAM_NAME', true)) ...
Parameters as Environment Variables
The parameter name-value pairs are automatically exported as environment variables when the build starts, allowing subsequent parts of the build configuration, such as shells triggered by build steps, to access those values using the following syntax (assuming that Jenkinsfile declares a "COLOR" parameter):
sh 'build has color ${COLOR}'
Jenkinsfile Groovy code invoked from the script can only access parameters using the params.paramName form and not as environment variables, as environment variables are exported and available to processes created by the Jenkins JVM.