Jenkins Pipeline Parameters: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
Line 95: Line 95:


If the pipeline was configured to accept parameters using "Build with Parameters" option, once a parameter is defined in Jenkinsfile, and the Jenkinsfile committed to the repository on a specific branch, the multi-branch pipeline that tracks the branch automatically updates the pipeline UI for that branch, so the parameter become available in "Build with Parameters" associated with the branch.
If the pipeline was configured to accept parameters using "Build with Parameters" option, once a parameter is defined in Jenkinsfile, and the Jenkinsfile committed to the repository on a specific branch, the multi-branch pipeline that tracks the branch automatically updates the pipeline UI for that branch, so the parameter become available in "Build with Parameters" associated with the branch.
{{Warn|Jenkins does not know about the new parameters until it retrieves the Jenkinsfile, parses it and runs it, and the only way to do that is to run a build, which will be based on the old Jenkinsfile. When something is changed in the Jenkinsfile, the next build will run with the "old" Jenkinsfile, but pick up and process the new Jenkinsfile for the build after that.}}


When the build is parameterized, the "Build Now" control is replaced by "Build with Parameters", which allows the user the option to specify values for each defined parameter. If they choose not to do anything, the build will start with the "Default Value". An new value specified in the UI will override the default specified in Jenkinsfile.
When the build is parameterized, the "Build Now" control is replaced by "Build with Parameters", which allows the user the option to specify values for each defined parameter. If they choose not to do anything, the build will start with the "Default Value". An new value specified in the UI will override the default specified in Jenkinsfile.

Revision as of 17:59, 21 April 2020

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, 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.

Parameter Declaration

A parameter is declared in the pipeline's Jenkinsfile with a different syntax depending on whether the pipeline is declarative or scripted. If the pipeline was configured to accept parameters using "Build with Parameters" option, once the Jenkinsfile is committed to the repository, the Jenkins server monitoring the branch will automatically update the UI based on the new Jenkinsfile, making the parameter available in the UI. For more details see Relationship between the Pipeline UI and Jenkinsfile Parameters below. As such, 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 and a description can be specified when the parameter is declared. Each parameter should have a unique name. Spaces are not permitted in parameter names.

Declarative Pipeline Paramenter Declaration

Declarative pipelines support parameters by default, with the parameters directive.

Scripted Pipeline Paramenter Declaration

properties([

  parameters([

    string(
        name: 'POD_MEMORY_LIMIT_Gi',
        defaultValue: '8', 
        description: 'The pod\'s cgroups memory limit, in Gi')

  ])
])

Multi-line description:

properties([
  parameters([
    string(
        name: 'something'
        description: """
    This is a 
    multi-line
    description
    """.stripIndent()
  ])
])

Parameters Types

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

String

properties([
  parameters([
    string(
        name: 'COLOR',
        defaultValue: 'blue', 
        description: 'Some color')
  ])
])

Multi-Line String Parameter

File Parameter

Accessing Parameters

In Jenkinsfile

The name-value pairs are exported as 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:

${POD_MEMORY_LIMIT_Gi}

The parameters are also accessible as members of the params variable throughout the Jenkinsfile (params.paramName is equivalent with params.get(paramName)):

echo "pod memory limit: ${params.POD_MEMORY_LIMIT_Gi}"

Jenkinsfile Groovy code can only access parameters using the params.paramName form and not as environment variables.

In Groovy Code

TODO, so far the parameters were passed into Groovy code as arguments of constructors and function calls form Jenkinsfile.

Relationship Between the Pipeline UI and Jenkinsfile Parameters

If the pipeline was configured to accept parameters using "Build with Parameters" option, once a parameter is defined in Jenkinsfile, and the Jenkinsfile committed to the repository on a specific branch, the multi-branch pipeline that tracks the branch automatically updates the pipeline UI for that branch, so the parameter become available in "Build with Parameters" associated with the branch.


Jenkins does not know about the new parameters until it retrieves the Jenkinsfile, parses it and runs it, and the only way to do that is to run a build, which will be based on the old Jenkinsfile. When something is changed in the Jenkinsfile, the next build will run with the "old" Jenkinsfile, but pick up and process the new Jenkinsfile for the build after that.

When the build is parameterized, the "Build Now" control is replaced by "Build with Parameters", which allows the user the option to specify values for each defined parameter. If they choose not to do anything, the build will start with the "Default Value". An 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
)