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