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

Environmental variables are always empty in email-ext plugin

    • Icon: Improvement Improvement
    • Resolution: Fixed
    • Icon: Minor Minor
    • email-ext-plugin
    • Jenkins version 2.235.1
      Email Extension Plugin version 2.69
      Token Macro Plugin version 2.12
    • 270.v8c2ce50dc4fc

      It seems as if environmental variables don't work with the emailext plugin. I am using declarative pipelines, but regardless of what I try the ${ENV, var=""} returns nothing. I can see that the double quoted subject "$VERSION" is correctly replaced and other tokens work such as single quoted '${BUILD_STATUS}' work, but '${ENV, var=""}' and '${ENV, var="VERSION"}' are always replaced empty. Same occurs with variables such as $PATH.

       

      pipeline {
        environment {
          VERSION = "1.0.0"
        }
       
        // ...
        // stages
        // ...
      
        post {
          always {
            emailext (
              to: 'DEFAULT_RECIPIENTS',
              subject: "$VERSION",
              body: '${ENV, var="VERSION"}'
            )
          }
        }
      }
      

       

      Regards

      Erik Hughes

          [JENKINS-63551] Environmental variables are always empty in email-ext plugin

          Alex Earl added a comment -

          This was sort of purposeful since you can just use the groovy variable interpolation to access any pipeline variables. Is there a specific use case that you need this for?

          Alex Earl added a comment - This was sort of purposeful since you can just use the groovy variable interpolation to access any pipeline variables. Is there a specific use case that you need this for?

          Erik Hughes added a comment - - edited

          Thank you for taking you time to answer slide_o_mix. First to answer your question, I would like to set a variable containing the "new release version" from a pipeline step. I know there are some limitations on setting variables from steps outlined in this stackoverflow answer, but it seems possible. However the issue exists regardless of variable chosen from the build environment, as seen in the description above. In my mail, which is HTML formatted, set as the "Default Content", the following is written:

          <h1>The new release will be ${ENV, var="VERSION"}, go forth and test!</h1>
          

          and in my pipeline it is referenced as such:

          emailext (
            body: '$DEFAULT_CONTENT'
            // ...
          )

          With the above in mind I was under the impression that ENV was the right choice as the documentation under "Content Token Reference" states:

          ${ENV, var="VARIABLENAME"}: Expands to an environment variable (specified here as VARIABLENAME) from the build environment. Note that this does not include any variables set by the build scripts themselves, only those set by Jenkins and other plugins. 

          Erik Hughes added a comment - - edited Thank you for taking you time to answer slide_o_mix . First to answer your question, I would like to set a variable containing the "new release version" from a pipeline step. I know there are some limitations on setting variables from steps outlined in this stackoverflow answer , but it seems possible. However the issue exists regardless of variable chosen from the build environment, as seen in the description above. In my mail, which is HTML formatted, set as the "Default Content", the following is written: <h1> The new release will be ${ENV, var= "VERSION" }, go forth and test! </h1> and in my pipeline it is referenced as such: emailext ( body: '$DEFAULT_CONTENT' // ... ) With the above in mind I was under the impression that ENV was the right choice as the documentation under "Content Token Reference" states: ${ENV, var="VARIABLENAME"}: Expands to an environment variable (specified here as VARIABLENAME) from the build environment. Note that this does not include any variables set by the build scripts themselves, only those set by Jenkins and other plugins. 

          Alex Earl added a comment -

          Ok, the usage of DEFAULT_CONTENT makes more sense to me now why you would want this. I'll see if I can get access to those variables. They work differently in pipeline.

          Alex Earl added a comment - Ok, the usage of DEFAULT_CONTENT makes more sense to me now why you would want this. I'll see if I can get access to those variables. They work differently in pipeline.

          Alex Earl added a comment -

          Alex Earl added a comment - https://github.com/jenkinsci/token-macro-plugin/pull/87

          The pull request was merged and version 270.v8c2ce50dc4fc of the Token Macro plugin was released. Does this issue still need changes in the Email Extension Plugin as well, or can this now be resolved?

          Kalle Niemitalo added a comment - The pull request was merged and version 270.v8c2ce50dc4fc of the Token Macro plugin was released. Does this issue still need changes in the Email Extension Plugin as well, or can this now be resolved?

          Alex Earl added a comment -

          I believe this can be closed, there shouldn't be any changes needed in email-ext.

          Alex Earl added a comment - I believe this can be closed, there shouldn't be any changes needed in email-ext.

            slide_o_mix Alex Earl
            seb_erik_hughes Erik Hughes
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: