-
Bug
-
Resolution: Won't Fix
-
Minor
-
Linux Master
Windows Node
The email-ext lost a feature between
working: Jenkins 2.51, email-ext 2.56
not working: Jenkins 2.54, email-ext 2.57-2
The template cannot reside on the slave node anymore, the template file is not found anymore with absolute path. The following pipeline code on inside a Windows slave node:
def email_template_file = pwd([tmp: true]) + "\\email_template_file.jelly"; writeFile([file: email_template_file, text: content_template]); emailext body: '${JELLY_SCRIPT,template="' + email_template_file.replaceAll('[\\\\]','/') + '"}'
The email got send but the template is no more found, now give the following results into the email body:
Jelly file [c:/Jenkins/workspace/CAD_CPP/CAD_CPP_ContinuousBuild@tmp/email_template_file.jelly] was not found in$JENKINS_HOME/email-templates.
The workaround is to save the email template on the master (hope no other does the same at the same time or use guid into the filename):
def email_template_file = "testid.html"; node('master') { writeFile([file: "${JENKINS_HOME}/email-templates/" + email_template_file, text: content_template]); emailext body: '${JELLY_SCRIPT,template="' + email_template_file.replaceAll('[\\\\]','/') + '"}', subject: 'test subject', to: 'test@test.com', replyTo: 'jenkins@test.com', mimeType: 'text/html'; }
This is used when you need to determine which section of the email template must be used at run time and based on run results. The pipeline script concat email template section together and then use the results as the final email template.
Now it's locking the template path to a relative path on the master and on top of it, it enforce the ${JENKINS_HOME}/email-templates folder.
[JENKINS-43903] email-ext jelly template slave node absolute path no more handled
That's sad that this feature is gone, and I guess for the name of security again. How one generate a dynamic template on node and manage to send it properly now? right now I have to stash the template generated on a node, check for a lock file and unstash on the master, send the email and release the lock file on the master. It doesn't feel like a funny Jenkinsfile sequence only to send an email. I still can live with it, but my guess is that newcomer will have trouble with it if they venture with dynamic template (email template content depends on the build sequence used into the jenkinsfile and the result of it).
I know I wish it wasn't the case but as one of the more popular plugins I have to address security issues when they are raised. There is a lock pipeline plugin that can simplify your steps there by wrapping the copy file and send email in a lock block that will wait on a specified global lock. Alternatively you can generate the html of the email in the pipeline itself or in a pipeline library. These use the groovy sandboxing and as such are not as open to security problems.
vipi voxa
added a comment - 
higher security introduces kind of less security, now e.g. email templates, used to managed by their own projects (have multi project environment here using one jenkins instance with many nodes for many different projects) stored on node level, have to be applied via jenkins admin. And in reality admin is not going through every single line of email template, some of them are pretty cumbersome ....all admin does - just applies script by request.
Also this additional security reason, introduces more manual steps to the process, which we kind of trying to reduce here - before, auto builds might have used templates from a source control dir, checked out and operated, obviously, on node level, now it is not the case.
vipi voxa
added a comment - higher security introduces kind of less security, now e.g. email templates, used to managed by their own projects (have multi project environment here using one jenkins instance with many nodes for many different projects) stored on node level, have to be applied via jenkins admin. And in reality admin is not going through every single line of email template, some of them are pretty cumbersome ....all admin does - just applies script by request.
Also this additional security reason, introduces more manual steps to the process, which we kind of trying to reduce here - before, auto builds might have used templates from a source control dir, checked out and operated, obviously, on node level, now it is not the case. I agree but I have to support security, if someone wants to implement a way of keeping the templates in a SCM like we can do with pipeline libs now I will accept a pull
This was changed for security reasons
If it fails that check it gives not found