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

Changing a boolean parameter at build time has no effect on conditional execution of a stage

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Not A Defect
    • Environment:
    • Similar Issues:
    • Sprint:
      Declarative - 1.2

      Description

      Summary:
      Given a Declarative Pipeline with a boolean parameter, which has a default setting of true, one might use this boolean to conditionally execute, or not execute, a particular stage. The syntax I've used to do this is similar to that shown in JENKINS-44298. It appears that changing this boolean at runtime, via the Jenkins UI, has no effect on whether or not the stage gets run.

      Assumptions:
      I'm working under the assumption that, a boolean parameter set up in the parameters

      { ... } section of a pipeline, used in a when { expression { ... }

      } condition written like this:

                  when {
                      expression {
                          return TRUE_OR_FALSE
                      }
                  }
      

      is a valid way of deciding whether or not a stage gets run. Here, if TRUE_OR_FALSE is set to `true`, it'll run. If it's set to false, it won't. Similarly, if it were written like this:

                  when {
                      expression {
                          return !TRUE_OR_FALSE
                      }
                  }
      

      The stage only gets run if TRUE_OR_FALSE is set to `false`.

      I found this approach while working on issue JENKINS-44298.

      Steps to recreate:
      1. Create a new Pipeline job on your Jenkins, and use this as its code:

      pipeline {
          agent any
          parameters {
              // Default value here is true.
              booleanParam(name: 'TRUE_OR_FALSE', defaultValue: true, description: 'This boolean defaults to true!') 
          }
          stages {
              stage('parallel-1') {
                  when {
                      expression {
                          // Given our default value is true, this should 
                          // run if I don't change the parameter from its 
                          // default value of true, to false.
                          return TRUE_OR_FALSE
                      }
                  }
                  steps {
                      echo "MUST BE TRUE"
                  } // end of steps
              } // end of stage
          } // end stages
      }
      

      2. Run this Pipeline by clicking "Build" on the left. The first time you do so, it'll fail anyway, because of a different bug that I'll look for / open separately. Nevermind that for now.

      3. Do a full page refresh in the UI, and the "Build" link has changed to "Build with parameters." Click this link, and leave the defaults. The boolean will be defaulted to True:

      Go ahead and run it this way, and it'll run correctly.

      4. Now, run it again, this time changing the parameter to false:

      5. The stage will still run, as if you had not set the parameter to false.

        Attachments

          Activity

          Hide
          abayer Andrew Bayer added a comment -

          So my guess here is that the parameter is actually getting represented as a String rather than a boolean here - which is not ideal. I'll need to test that further to be sure, but I'd guess that if you did return TRUE_OR_FALSE == "true", it'd work. I'll determine if this is a bug in Declarative's handling or deeper in the stack.

          Show
          abayer Andrew Bayer added a comment - So my guess here is that the parameter is actually getting represented as a String rather than a boolean here - which is not ideal. I'll need to test that further to be sure, but I'd guess that if you did return TRUE_OR_FALSE == "true" , it'd work. I'll determine if this is a bug in Declarative's handling or deeper in the stack.
          Hide
          abayer Andrew Bayer added a comment -

          Ok, yeah, it's referring to them as TRUE_OR_FALSE rather than params.TRUE_OR_FALSE that's creating the problem - if you use params.TRUE_OR_FALSE, it doesn't fail the first time and does the right thing. I can't remember off the top of my head how the params values end up made available as TRUE_OR_FALSE etc, but whatever's doing that is the problem. Digging into that now.

          Show
          abayer Andrew Bayer added a comment - Ok, yeah, it's referring to them as TRUE_OR_FALSE rather than params.TRUE_OR_FALSE that's creating the problem - if you use params.TRUE_OR_FALSE , it doesn't fail the first time and does the right thing. I can't remember off the top of my head how the params values end up made available as TRUE_OR_FALSE etc, but whatever's doing that is the problem. Digging into that now.
          Hide
          abayer Andrew Bayer added a comment -

          Got it - the build parameters get injected into the build environment over in https://github.com/jenkinsci/workflow-job-plugin/pull/24/files, and EnvVars is, behind the scenes, a String,String map - so any environment value will always be typed as a String, and return "false" is returning the String "false", and expression will treat any value other than null or false as if it were true. So...yeah. The right way to handle this is to always use params.TRUE_OR_FALSE.

          Show
          abayer Andrew Bayer added a comment - Got it - the build parameters get injected into the build environment over in https://github.com/jenkinsci/workflow-job-plugin/pull/24/files , and EnvVars is, behind the scenes, a String,String map - so any environment value will always be typed as a String , and return "false" is returning the String "false" , and expression will treat any value other than null or false as if it were true. So...yeah. The right way to handle this is to always use params.TRUE_OR_FALSE .
          Hide
          bitwiseman Liam Newman added a comment -

          Bulk closing resolved issues.

          Show
          bitwiseman Liam Newman added a comment - Bulk closing resolved issues.

            People

            Assignee:
            jackenliu jianheng liu
            Reporter:
            kshultz Karl Shultz
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: