Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-40574

Pipeline build parameters are null in first build

XMLWordPrintable

      Parameters which are set in properties in a pipeline build are null the first time the build is run, even if they are given default values. On subsequent builds, the parameters have values as expected.

      Example: create a new Pipeline job and define the pipeline script like this in the build config:

      properties([
  [$class: 'ParametersDefinitionProperty',
    parameterDefinitions: [
      [$class: 'StringParameterDefinition',
        name: 'SOME_PARAMETER',
        defaultValue: 'some value',
        description: 'A test parameter']]
  ]
])

echo "Value of parameter:"
echo env.SOME_PARAMETER

      Run the build by clicking "Build" (note that this says "Build" rather than "Build with Parameters" unless the build has been run at least once). The console output is:

      [Pipeline] echo
Value of parameter:
[Pipeline] echo
null

      Run the build a second time by clicking "Build with Parameters" and then confirming the default value. The console output is now:

      [Pipeline] echo
Value of parameter:
[Pipeline] echo
some value

      If you refer to the parameter directly using SOME_PARAMETER rather than env.SOME_PARAMETER, the first build fails with a groovy.lang.MissingPropertyException instead.

      This isn't so bad when you're configuring a single new job, but it becomes a real problem for multibranch pipeline jobs, because the first build of every branch always fails unless the pipeline script does extra work to handle the missing parameter.

          [JENKINS-40574] Pipeline build parameters are null in first build

          Suzanne Hamilton created issue -
          Suzanne Hamilton made changes -
          Description Original: Parameters which are set in {{properties}} in a pipeline build are null the first time the build is run, even if they are given default values. On subsequent builds, the parameters have values as expected.

          Example: create a new Pipeline job and define the pipeline script like this in the build config:

          {code}
          properties([
            [$class: 'ParametersDefinitionProperty',
              parameterDefinitions: [
                [$class: 'StringParameterDefinition',
                  name: 'SOME_PARAMETER',
                  defaultValue: 'some value',
                  description: 'A test parameter']]
            ]
          ])

          echo "Value of parameter:"
          echo env.SOME_PARAMETER
          {code}

          Run the build by clicking "Build" (note that this says "Build" rather than "Build with Parameters"). The console output is:

          {code}
          [Pipeline] echo
          Value of parameter:
          [Pipeline] echo
          null
          {code}

          Run the build a second time by clicking "Build with Parameters" and then confirming the default value. The console output is now:

          {code}
          [Pipeline] echo
          Value of parameter:
          [Pipeline] echo
          some value
          {code}

          If you refer to the parameter directly using {{SOME_PARAMETER}} rather than {{env.SOME_PARAMETER}}, the first build fails with a {{groovy.lang.MissingPropertyException}} instead.

          This isn't so bad when you're configuring a single new job, but it becomes a real problem for multibranch pipeline jobs, because the first build of every branch always fails unless the pipeline script does extra work to handle the missing parameter.           		New: Parameters which are set in {{properties}} in a pipeline build are null the first time the build is run, even if they are given default values. On subsequent builds, the parameters have values as expected.

          Example: create a new Pipeline job and define the pipeline script like this in the build config:

          {code}
          properties([
            [$class: 'ParametersDefinitionProperty',
              parameterDefinitions: [
                [$class: 'StringParameterDefinition',
                  name: 'SOME_PARAMETER',
                  defaultValue: 'some value',
                  description: 'A test parameter']]
            ]
          ])

          echo "Value of parameter:"
          echo env.SOME_PARAMETER
          {code}

          Run the build by clicking "Build" (note that this says "Build" rather than "Build with Parameters" unless the build has been run at least once). The console output is:

          {code}
          [Pipeline] echo
          Value of parameter:
          [Pipeline] echo
          null
          {code}

          Run the build a second time by clicking "Build with Parameters" and then confirming the default value. The console output is now:

          {code}
          [Pipeline] echo
          Value of parameter:
          [Pipeline] echo
          some value
          {code}

          If you refer to the parameter directly using {{SOME_PARAMETER}} rather than {{env.SOME_PARAMETER}}, the first build fails with a {{groovy.lang.MissingPropertyException}} instead.

          This isn't so bad when you're configuring a single new job, but it becomes a real problem for multibranch pipeline jobs, because the first build of every branch always fails unless the pipeline script does extra work to handle the missing parameter.
          Glib Briia made changes -
          Priority Original: Minor [ 4 ] New: Major [ 3 ]
          anderson oliveria made changes -
          Priority Original: Major [ 3 ] New: Critical [ 2 ]
          anderson oliveria made changes -
          Labels New: Parameters Pipeline
          anderson oliveria made changes -
          Labels Original: Parameters Pipeline New: Build Jenkinsfile Parameters Pipeline
          Marcel 'childNo͡.de' Trautwein made changes -
          Link New: This issue is duplicated by JENKINS-42922 [ JENKINS-42922 ]
          Marcel 'childNo͡.de' Trautwein made changes -
          Link New: This issue is duplicated by JENKINS-41929 [ JENKINS-41929 ]
          Andrew Bayer made changes -
          Link New: This issue duplicates JENKINS-41929 [ JENKINS-41929 ]
          Andrew Bayer made changes -
          Resolution New: Duplicate [ 3 ]
          Status Original: Open [ 1 ] New: Resolved [ 5 ]
          Marat Radchenko made changes -
          Link Original: This issue is duplicated by JENKINS-41929 [ JENKINS-41929 ]

            Unassigned Unassigned
            suzannehamilton Suzanne Hamilton
            Votes:
            9 Vote for this issue
            Watchers:
            17 Start watching this issue

              Created:
              Updated:
              Resolved: