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

All boolean parameters get set to true when used to set env vars.

    Details

    • Similar Issues:

      Description

      Using boolean parameters to set environment variables doesn't work for some crazy reason.

      pipeline {
          agent none
          options {
              ansiColor('xterm')
              skipDefaultCheckout()
              durabilityHint('PERFORMANCE_OPTIMIZED')
          }
          parameters {
              booleanParam(
                  name: 'lazyBuild',
                  defaultValue: true,
                  description: 'Skip build'
              )
          }
          stages {
              stage('WTF') {
                  agent {
                      label 'master'
                  }
                  environment {
                      IS_LAZY = "${(params.lazyBuild) ? 't' : 'f'}"
                      IS_NOT_LAZY = "${(!params.lazyBuild) ? 't' : 'f'}"
                  }
      
                  steps {
                      sh 'echo IS_LAZY: $IS_LAZY'
                      sh 'echo IS_NOT_LAZY: $IS_NOT_LAZY'
                  }
              }
          }
      }
      

      Output:

      [00-build] Running shell script
      + echo IS_LAZY: t
      IS_LAZY: t
      [Pipeline] sh
      [00-build] Running shell script
      + echo IS_NOT_LAZY: t
      IS_NOT_LAZY: t
      

        Attachments

          Issue Links

            Activity

            Hide
            dnusbaum Devin Nusbaum added a comment - - edited

            I'm not quite sure what's going on here, but I was able to reproduce it. Looks like someone in JENKINS-47881 also mentioned a similar issues using the ternary operator for an environment variable. CC Andrew Bayer, are we all missing something obvious here?

            pipeline {
                agent any
                parameters {
                  booleanParam defaultValue: true, description: '', name: 'p1'
                }
                environment {
                    NOT_P1 = "${(!params.p1) ? 'true' : 'false'}"
                }
                stages {
                    stage('JENKINS-54047') {
                        steps {
                            // If p1 == true, then this prints "expecting false, got true"
                            // If p1 == false, then this prints "expecting true, got false"
                            echo "expecting ${!p1}, got ${NOT_P1}"
                        }
                    }
                }
            } 
            Show
            dnusbaum Devin Nusbaum added a comment - - edited I'm not quite sure what's going on here, but I was able to reproduce it. Looks like someone in  JENKINS-47881 also mentioned a similar issues using the ternary operator for an environment variable. CC Andrew Bayer , are we all missing something obvious here? pipeline { agent any parameters { booleanParam defaultValue: true , description: '', name: ' p1' } environment { NOT_P1 = "${(!params.p1) ? ' true ' : ' false ' }" } stages { stage( 'JENKINS-54047' ) { steps { // If p1 == true , then this prints "expecting false , got true " // If p1 == false , then this prints "expecting true , got false " echo "expecting ${!p1}, got ${NOT_P1}" } } } }
            Hide
            abayer Andrew Bayer added a comment -

            The JENKINS-47881 thing is a red herring - the actual problem here is that NotExpression isn't being handled properly in the environment value resolution - it's a descendant of BooleanExpression, but I wasn't distinguishing them, so !foo would end up being just foo. D'oh. PR incoming.

            Show
            abayer Andrew Bayer added a comment - The JENKINS-47881 thing is a red herring - the actual problem here is that NotExpression isn't being handled properly in the environment value resolution - it's a descendant of BooleanExpression , but I wasn't distinguishing them, so !foo would end up being just foo . D'oh. PR incoming.
            Show
            abayer Andrew Bayer added a comment - PR up at  https://github.com/jenkinsci/pipeline-model-definition-plugin/pull/290
            Hide
            akdor1154 Jarrad Whitaker added a comment -

            Thanks for quickly looking at this.
            From an unfamiliar dev's point of view, it's a bit eyebrow raising that this sort of error-prone transformation is necessary.. isn't the point of using a DSL based on groovy that you can rely on groovy for basic stuff like this?

            Show
            akdor1154 Jarrad Whitaker added a comment - Thanks for quickly looking at this. From an unfamiliar dev's point of view, it's a bit eyebrow raising that this sort of error-prone transformation is necessary.. isn't the point of using a DSL based on groovy that you can rely on groovy for basic stuff like this?
            Hide
            abayer Andrew Bayer added a comment -

            This'll be in the upcoming 1.3.3 release.

            Show
            abayer Andrew Bayer added a comment - This'll be in the upcoming 1.3.3 release.
            Hide
            abayer Andrew Bayer added a comment -

            Jarrad Whitaker Yeah, it's a bit annoying - complicated DSLs like this are hairier than I'd like them to be, but we actually see a lot fewer bugs like this show up than I would have expected.

            Show
            abayer Andrew Bayer added a comment - Jarrad Whitaker Yeah, it's a bit annoying - complicated DSLs like this are hairier than I'd like them to be, but we actually see a lot fewer bugs like this show up than I would have expected.

              People

              • Assignee:
                abayer Andrew Bayer
                Reporter:
                akdor1154 Jarrad Whitaker
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: