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

Environmental variables are always empty in email-ext plugin

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: Open (View Workflow)
    • Priority: Minor
    • Resolution: Unresolved
    • Component/s: email-ext-plugin
    • Labels:
    • Environment:
      Jenkins version 2.235.1
      Email Extension Plugin version 2.69
      Token Macro Plugin version 2.12
    • Similar Issues:

      Description

      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

        Attachments

          Activity

          Hide
          slide_o_mix 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?

          Show
          slide_o_mix 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?
          Hide
          seb_erik_hughes Erik Hughes added a comment - - edited

          Thank you for taking you time to answer Alex Earl. 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. 

          Show
          seb_erik_hughes Erik Hughes added a comment - - edited Thank you for taking you time to answer Alex Earl . 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. 
          Hide
          slide_o_mix 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.

          Show
          slide_o_mix 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.

            People

            Assignee:
            Unassigned Unassigned
            Reporter:
            seb_erik_hughes Erik Hughes
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Dates

              Created:
              Updated: