Testing the latest version of the pipeline plugins and it appears that it's no longer possible to set empty environment variables.  The following works in some current declarative scripts I have still using v1.0.2:

      pipeline{
          environment{
             EMAIL_RECIPIENTS         = 'me@me.com' 
             EMAIL_RECIPIENTS_SUCCESS = ''
          }
          
          (some stages and steps)
      
          post {
              success {
                  echo 'Send Success message...'
                  buildEmailer (currentBuild.result, EMAIL_RECIPIENTS, EMAIL_RECIPIENTS_SUCCESS)
              }
              failure {
                  echo 'Send Failed message...'
                  buildEmailer (currentBuild.result, EMAIL_RECIPIENTS, EMAIL_RECIPIENTS_SUCCESS) 
              } 
          }
      }

      I have emailing logic in shared library (buildEmailer) and do some processing if the incoming variable is blank. The above causes no trouble in plugin version 1.0.2, but in 1.1.2, I get:

      groovy.lang.MissingPropertyException: No such property: EMAIL_RECIPIENTS_SUCCESS for class: WorkflowScript
      at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap(ScriptBytecodeAdapter.java:53)
      at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.getProperty(ScriptBytecodeAdapter.java:458)
      at com.cloudbees.groovy.cps.sandbox.DefaultInvoker.getProperty(DefaultInvoker.java:33)
      at com.cloudbees.groovy.cps.impl.PropertyAccessBlock.rawGet(PropertyAccessBlock.java:20)
      at WorkflowScript.run(WorkflowScript:127)
      ...

      However, the script is OK if I move things around and set the variables inside a script {} section inside a stage{}. The reason this particular value is set but blank, is that I let this value be optional and let developers update the desired property to what they want in the build job. I could process some default value in the environment section, but since the scripts works with variables in a script section, and it was working in 1.0.2, it seems like this could be a bug with the environment section.

          [JENKINS-43632] Not Possible to Set Blank Environment Variables

          Jason Davis created issue -

          Andrew Bayer added a comment -

          Nice catch, I think I can fix this.

          Andrew Bayer added a comment - Nice catch, I think I can fix this.

          Andrew Bayer added a comment -

          Hrm. Honestly not yet sure how this worked in the first place! I'm able to reproduce this bug with a simple withEnv step outside of Declarative. Note that this is only happening when you're referring to the environment variable outside of a double-quoted string and without the env. prefix...

          Andrew Bayer added a comment - Hrm. Honestly not yet sure how this worked in the first place! I'm able to reproduce this bug with a simple withEnv step outside of Declarative. Note that this is only happening when you're referring to the environment variable outside of a double-quoted string and without the env. prefix...

          Andrew Bayer added a comment -

          Yup, verified that an empty-value environment variable won't end up in the environment by design - Jenkins' internal environment resolution will not include any 0-length env var. That's in core. Hmm.

          Andrew Bayer added a comment - Yup, verified that an empty-value environment variable won't end up in the environment by design - Jenkins' internal environment resolution will not include any 0-length env var. That's in core. Hmm.

          Jason Davis added a comment - - edited

          Yeah... I've only tried straight up declarative / environment section methods (no withEnv) and have only used env. in some shared library scripts I've written.  The only workaround I tried was to set the empty '' variables in stage -> step -> script {} section inside of a new "build setup" stage I wrote.  That was the first thing I tried, and since it allowed me to keep the library scripts unchanged, I didn't try another method.

          I did update all my pipeline plugins to bleeding edge as of yesterday morning.  I assumed since the change occurred in the environment section and the script{} workaround is OK, that the culprit was this plugin, but maybe the bug is elsewhere?    

          Or (I just saw your update about it being by design)

          It's not a bug and I've just gotten lucky up until this point.    Crud!  

          Jason Davis added a comment - - edited Yeah... I've only tried straight up declarative / environment section methods (no withEnv) and have only used env. in some shared library scripts I've written.  The only workaround I tried was to set the empty '' variables in stage -> step -> script {} section inside of a new "build setup" stage I wrote.  That was the first thing I tried, and since it allowed me to keep the library scripts unchanged, I didn't try another method. I did update all my pipeline plugins to bleeding edge as of yesterday morning.  I assumed since the change occurred in the environment section and the script{} workaround is OK, that the culprit was this plugin, but maybe the bug is elsewhere?      Or (I just saw your update about it being by design) It's not a bug and I've just gotten lucky up until this point.    Crud!  
          Andrew Bayer made changes -
          Resolution New: Not A Defect [ 7 ]
          Status Original: Open [ 1 ] New: Resolved [ 5 ]

          vishal kumar added a comment -

          jedavis:- May i know how did you fix this in your pipeline, because if i am trying to set a variable empty by default it takes the value  "null" and passed everywhere.

          vishal kumar added a comment - jedavis :- May i know how did you fix this in your pipeline, because if i am trying to set a variable empty by default it takes the value  "null" and passed everywhere.

          Vote for this issue is disabled for me.  Please count this as my +1 - Blue ocean USER INTERFACE should not drive the requirements for how a program displays its data - it should respond to the needs of the users and accommodate the use cases that customers need.  Clearly if the job description allows HTML for normal Jenkins use - then BO should accommodate this.

          Todd Lindstrom added a comment - Vote for this issue is disabled for me.  Please count this as my +1 - Blue ocean USER INTERFACE should not drive the requirements for how a program displays its data - it should respond to the needs of the users and accommodate the use cases that customers need.  Clearly if the job description allows HTML for normal Jenkins use - then BO should accommodate this.

          I would also consider this a bug. Environment variables with an empty string should be possible. It is not the same as unset.

          Christian Schneider added a comment - I would also consider this a bug. Environment variables with an empty string should be possible. It is not the same as unset.
          Christian Schneider made changes -
          Resolution Original: Not A Defect [ 7 ]
          Status Original: Resolved [ 5 ] New: Reopened [ 4 ]

            Unassigned Unassigned
            jedavis Jason Davis
            Votes:
            26 Vote for this issue
            Watchers:
            26 Start watching this issue

              Created:
              Updated: