Jenkins Pipeline Parameters: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
No edit summary
 
(183 intermediate revisions by the same user not shown)
Line 2: Line 2:
* https://wiki.jenkins.io/display/JENKINS/Parameterized+Build
* https://wiki.jenkins.io/display/JENKINS/Parameterized+Build
* https://jenkins.io/doc/book/pipeline/jenkinsfile/#handling-parameters
* https://jenkins.io/doc/book/pipeline/jenkinsfile/#handling-parameters
* https://devopscube.com/declarative-pipeline-parameters/


=Internal=
=Internal=
Line 10: Line 11:
=Overview=
=Overview=


A parameter enables the pipeline to prompt the user for a piece of information to be passed into the build. Each parameter has a "Name" and a "Value", which depends on the parameter type. A "Default Value" can be specified. The name-value pairs will be exported as [[Jenkins Pipeline Environment Variables|environment variables]] when the build starts, allowing subsequent parts of the build configuration, such as build steps, to access those values using the following syntax:
A parameter is a way to configure a [[Jenkins_Concepts#Pipeline|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.
${PARAMETER_NAME}
 
The parameter values can also be retrieved in a [[Jenkins_Concepts#Jenkinsfile|Jenkinsfile]] with the following syntax:
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.
 
<span id='Parameterized_Build'></span><span id='Build_with_Parameters'></span>A pipeline that exposes parameters enables '''parameterized builds''' and its UI will offer the choice to "Build with Parameters":
 
:::[[Image:Build_with_Parameters.png|200px]]
 
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|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 <code>this.params</code>, which is a read-only Map that maintains parameter name - parameter value association. <code>params</code> is a pipeline [[Jenkins_Concepts#params_.28Pipeline_Parameters.29|global variable]]. Additional documentation on the <code>params</code> global variable is available at http&#58;//<jenkins-instance-url>/pipeline-syntax/globals#params.
 
For more details on accessing parameters see [[#Accessing_Parameters|Accessing Parameters]] below. For more details about the data structures associated with a pipeline at runtime see: {{Internal|Jenkins_Pipeline_Syntax#Scripted_Pipeline_at_Runtime|Scripted Pipeline at Runtime}}
 
=Parameter Declaration=
 
The preferred way to define pipeline parameters is to declare them in [[#Jenkinsfile_Parameters|Jenkinsfile]]. It is also possible to declare them in the [[#UI_Parameters|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'''.
 
{{Warn|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 [[Jenkins_Concepts#Jenkinsfile|Jenkinsfile]] using a different syntax depending on whether the pipeline is [[Jenkins_Pipeline_Syntax#Declarative_Pipeline|declarative]] or [[Jenkins_Pipeline_Syntax#Scripted_Pipeline|scripted]].
===Scripted Pipeline Parameter Declaration===
Parameters can be declared a scripted pipeline Jenkinsfile using the syntax shown below:
 
<syntaxhighlight lang='groovy'>
<syntaxhighlight lang='groovy'>
properties([
properties([
  ...
   parameters([
   parameters([
     string(
     string(name: 'color', defaultValue: 'blue', description: 'The build\'s color'),
      name: 'branch',
     ...
      defaultValue: 'develop',
  ])
      description: 'Branch name or branch head\' SHA1 hash to be used to run this build on.'
    ),
     string(
      name: 'artifact version',
      description: 'The version of the artifact (ex: 1.0.0-build.1)'
    ),
    text(
      name: 'Test Packages,
      defaultValue: 'test-package-1',
    )
])
])
])
</syntaxhighlight>
</syntaxhighlight>


They can be reported, for debugging purposes, as follows:
For a multi-line description, use this syntax:
<syntaxhighlight lang='groovy'>
properties([
  parameters([
    string(name: 'color', defaultValue: 'blue', description: """
  This is a
  multi-line
  description
""".stripIndent())
  ])
])
</syntaxhighlight>
 
 
For a full list of parameter types that can be added see [[#Parameter_Types|Parameter Types]] below.
 
===Declarative Pipeline Paramenter Declaration===
Declarative pipelines support parameters by default, with the [[Jenkins_Pipeline_Syntax#parameters|parameters]] directive.
 
==Parameter Definition Update Cycle==
 
{{Warn|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_Parameters|Jenkinsfile parameter section]].
 
==UI Parameters==
 
The parameters can be declared in the UI when the pipeline is defined by checking the "[[Jenkins_Simple_Pipeline_Configuration#This_project_is_parameterized|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|Parameter Types]] below.
 
⚠️ As mentioned in the [[#Parameter_Declaration|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==
[[Jenkins_Pipeline_Syntax#Scripted_Pipeline|Scripted pipeline]] syntax:
<syntaxhighlight lang='groovy'>
properties([
  parameters([
        string(name: 'color', defaultValue: 'blue', description: 'The build color')
  ])
])
</syntaxhighlight>
 
==Multi-Line String Parameter==
A [[#String_Parameter|String parameter]] that allows newline characters.
[[Jenkins_Pipeline_Syntax#Scripted_Pipeline|Scripted pipeline]] syntax:
 
<font color=darkgray>TODO</font>


==Choice Parameter==
A pre-defined set of strings from which a user can pick a value. [[Jenkins_Pipeline_Syntax#Scripted_Pipeline|Scripted pipeline]] syntax:
<syntaxhighlight lang='groovy'>
<syntaxhighlight lang='groovy'>
params.get(propertyName)
properties([
  parameters([
    choice(name: 'size', choices: ['S', 'M', 'L'],  description: 'Size choice (S/M/L)')
])
</syntaxhighlight>
==File Parameter==
The full path to a file on the filesystem. [[Jenkins_Pipeline_Syntax#Scripted_Pipeline|Scripted pipeline]] syntax: <font color=darkgray>TODO</font>
==Credentials==
A pre-defined Jenkins credential. [[Jenkins_Pipeline_Syntax#Scripted_Pipeline|Scripted pipeline]] syntax: <font color=darkgray>TODO</font>
==Password==
Similar to the [[#Credentials|Credentials]] type, but allows passing a plain text parameter specific to the job or pipeline. [[Jenkins_Pipeline_Syntax#Scripted_Pipeline|Scripted pipeline]] syntax: <font color=darkgray>TODO</font>
==Boolean==
<syntaxhighlight lang='groovy'>
properties([
  parameters([
    booleanParam(name: 'coffee-flavored', defaultValue: true,  description: 'something')
])
</syntaxhighlight>
</syntaxhighlight>


Each parameter should have a unique name. Spaces are not permitted in parameter names.
==Run==
An absolute URL to a single run of another job. [[Jenkins_Pipeline_Syntax#Scripted_Pipeline|Scripted pipeline]] syntax: <font color=darkgray>TODO</font>


When the build is parameterized, the "Build Now" control will be replaced with "Build with Parameters", where users will be prompted to specify values for each defined parameter. If they choose not to do anything, the build will start with the "Default Value". If the build is started automatically, the "Default Value" is used, unless the build triggering function provides the corresponding values, as follows:
==Input Parameter==
{{External|https://www.jenkins.io/doc/pipeline/steps/pipeline-input-step/}}
 
==Custom Parameters==
 
<font color=darkgray>TODO:</font> https://wiki.jenkins.io/display/jenkins/parameterized+build
 
=Setting Parameter Values=
If parameters are defined in Jenkinsfile, defaults can be set there using the <code>defaultValue: '...'</code> syntax. Those defaults will reflect in the UI after a build cycle, as described in the [[#Parameter_Definition_Update_Cycle|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:


<syntaxhighlight lang='groovy'>
<syntaxhighlight lang='groovy'>
Line 60: Line 149:
</syntaxhighlight>
</syntaxhighlight>


When a parameterized build is in the queue, attempting 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.
=Accessing Parameters=
 
The Map containing the build's parameters can be accessed at runtime from the Jenkinsfile with:


=Relationship Between UI and Jenkinsfile Parameters=
<syntaxhighlight lang='groovy'>
this.params
</syntaxhighlight>


<font color=darkgray>
The existence of a parameter can be checked with:
* <span id='TODO_nw3td'></span>TODO_nw3td What is the relationship between the parameters declared in the pipeline's UI and the parameters declared in the pipleline's Jenkinsfile?
* <span id='TODO_n88Y6'></span>TODO_n88Y6 Establish the precedence between a defaultValue declared in the "parameter" section in Jenkinsfile and one declared for the same parameter in the UI. It seems the file value influences the UI value.
</font>


<syntaxhighlight lang='groovy'>
print "exists: " + this.params.containsKey(paramName)
</syntaxhighlight>
If the parameter exists, its value can be accessed with:
<syntaxhighlight lang='groovy'>
def paramName = "color"
print "parameter value: " + this.params.get(paramName)
</syntaxhighlight>
or with:
<syntaxhighlight lang='groovy'>
print "parameter value: " + this.params.color
</syntaxhighlight>
If the parameter does not exist in the map, both examples will print "parameter value: null".
The <code>getOrDefault()</code> can supply a default value:
<syntaxhighlight lang='groovy'>
if (params.getOrDefault('BOOLEAN_PARAM_NAME', true)) ...
</syntaxhighlight>
==Parameters as Environment Variables==
The parameter name-value pairs are automatically exported as [[Jenkins_Pipeline_Environment_Variables#Accessing_Environment_Variables|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):
<syntaxhighlight lang='groovy'>
sh 'build has color ${COLOR}'
</syntaxhighlight>


==Parameters Types==
Jenkinsfile Groovy code invoked from the script can only access parameters using the <tt>params.paramName</tt> form and not as environment variables, as environment variables are exported and available to processes created by the Jenkins JVM.
===String===
===Multi-Line String Parameter===
===File Parameter===

Latest revision as of 04:21, 8 May 2021

External

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":

Build with Parameters.png

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:

Scripted Pipeline at Runtime

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

https://www.jenkins.io/doc/pipeline/steps/pipeline-input-step/

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.