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

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

    XMLWordPrintable

Details

    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

            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 abayer, 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}"
                        }
                    }
                }
            } 
            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 abayer , 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}" } } } }
            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.

            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.
            abayer Andrew Bayer added a comment - PR up at  https://github.com/jenkinsci/pipeline-model-definition-plugin/pull/290

            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?

            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?
            abayer Andrew Bayer added a comment -

            This'll be in the upcoming 1.3.3 release.

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

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

            abayer Andrew Bayer added a comment - akdor1154 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.
            bitwiseman Liam Newman added a comment -

            Bulk closing resolved issues.

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

            People

              abayer Andrew Bayer
              akdor1154 Jarrad Whitaker
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: