Created an attachment (id=342)
The patch for supporting HTML email

I have attached the patch here. Few points regarding the changes

– The email plugin would now have a dependency on groovy 1.5.6 in pom.xml

– I wanted to validate the script content. It would only check that it can be
compiled or not. But the current mechanism seems like uses GET request. But here
as the content can be large I would like it to be sent it as POST. The backend
code is there in ExtendedEmailPublisher.doMailContentCheck. Just need to wire it
up in UI

– Would post the example later!!

Added an example at
http://techkriti.wordpress.com/2008/08/30/using-groovy-with-hudson-to-send-rich-text-email/

Sub-component should be email-ext.

adding myself to CC list

Hey Chetan,

I'm trying to use your patch. When copy pasted the test summary related snippet
to my Default content field, it resulted in a Fatal error by showing the the
code is missing a "}" at line 49. Later when I fixed the stuff, the Hudson
console log shows its sending email. But I receive a blank mail.

I take back my comments. I did a partial copy of the Default content. I think
now I got it working. To me this patch is an excellent one and I recommend this
to be added as a feature to the email-ext. Its definitely a value-add.

I have been using Chetan's patch for a couple of months now. It has been a huge
value-add to my project. It has helped provide detailed failure diagnostics in
the rich text emails to testers. I hope this patch is incorporated.

• • • Issue 545 has been marked as a duplicate of this issue. ***

Created an attachment (id=929)
Updated patch for current svn of email-ext

I attached an updated version of Chetan's patch that applies to current svn of
email-ext. Two notes:
1) This is compilable but not yet tested
2) Since the patch was written, email-ext added arguments to its tokens..
argument support not added for groovy scripts (it'll use defaults for all
arguments).

I tried the updated patch (Sep 28). The defaultContentIsScript setting seems to
have no effect. However, the patch works with Advanced -> More Configuration
(expand) -> Content is Script.

I haven't tried to fix this.

I've applied the patch to the current trunk version of email-ext, and I'm pretty happy with the result. Groovy'sh email notifications are great!
What is preventing integration of this patch? I'm willing to help this patch find its way to the official Hudson releases.

I've modified mindless' patch to mesh better with trunk.

One big problem with the this implementation: the project default "is script" doesn't work at all. As a solution, I'd suggest changing the checkbox to a dropdown with the additional options "default", "yes", and "no".

Another problem: there is no global scripting.

Perhaps after we knock out these issues, we can put some user documentation together and release it in 2.5. I don't see a reason to sit on this issue for another year.

Code changed in hudson
User: : ashlux
Path:
trunk/www/changelog.html
http://fisheye4.cenqua.com/changelog/hudson/?cs=25796
Log:
Add JENKINS-5112 and JENKINS-2175.

We are using this patch successfully. Any idea when this script support will be added to email-ext plugin? This is a great feature and needed asap.

Thanks all.

I fixed isScript globally, added a charset option, and added functionality to interactively test the email template on past builds (attached as based_on_2009-09-28.patch). However, it's based on the patch from mindless, not the current email-ext. I used it with the attached svn-template.html.

I haven't done much programming in Hudson, so it's probably not ideal. In particular, I didn't get around to having the test in a project configuration default to (or choose from?) builds from that project. So, it's the same as in the global config.

I updated this patch and my additions to the head of the email-ext trunk as of 2010-02-12 (attached).

I also mirrored that svn trunk on github and this patch as the groovy branch, in case that's easier to work with:

http://github.com/jdbeutel/hudson-email-ext/network

(fair warning: it's my first time using git)

I attached fixed_tests_2010-02-12.patch, which includes fixes for the existing tests, and pushed that fix to github too.

Can you also apply the attached simple patch? text/html emails get are not well formatted in email clients without the <br> tags. Thanks

Having the plugin add <br> to the end of every line will cause problems for properly formatted templates that already have <br>, that split tags across lines, etc. Shouldn't the author of the template add <br> where they are needed, instead of having the plugin do it?

I found a couple bugs with isScript handling in the "Test Against Build" buttons I added. So, I attached a patch with fixes: another_fix_2010-02-19.patch, and pushed to http://github.com/jdbeutel/hudson-email-ext/network

The patches I've been attaching are the whole thing from the head of the trunk. The diffs between each patch are available on github.

Hmmm! In our case, the mail content is mostly based on the perforce change list descriptions and the tail output of the job run. Since we don't have control over both of these, we cannot have <br> instead of new lines. May be we can add a "Add <br> in place of new lines" user configurable option?

How about putting <pre> tags around those parts of the template?

Even though it messes up some other formatting, the <pre> tag seems to resolve my issue. Some times I find complicated ways to do simple things Thanks David

BTW, I have another patch for P4_CHANGELIST token (similar to SVN_REVISION). I will open a separate issue for that

I'm glad I could help. Sorry I can't really do stuff here or on the Perforce issue, though, because I'm not a committer (and I don't know Perforce and can't test it).

david_beutel, can you remove ${rootURL} from all the help= attributes (this gets prepended automatically) and change encode(this.value) to toValue(this) in all the checkUrl attributes.. thanks!
If you're willing to "support" this change by watching the bug tracker for a few weeks following release, perhaps we can get this committed soon.

I'm swamped this week, but I'll be happy to do it next week. Thanks!

I've done this update on http://github.com/jdbeutel/hudson-email-ext/network but I'll have to look into making a new patch file from these changes next week. I thought that `git diff master` would do it, but it's starting with a change in version from 1.319, which doesn't look right relative to the head...

I think I've got a good patch file now for the changes relative to head (attached as updated_on_2010-05-07.patch). Please let me know if you see any problems with it.

My problem with the diff on Friday was that my local master was not up to date with my remote master, with which I'm tracking the head. (I'm still learning git. The details at http://github.com/jdbeutel/hudson-email-ext/network may be useful.)

I can support this change for a few weeks, if I can get copied on the notifications for this email-ext component in JIRA.

I updated from the head again, attached as updated_on_2010-05-18.patch. This adds just one commit to avoid some errors and warnings in Eclipse.

The latest patch is as of the end of May, but email-ext has had a lot of changes since then. (You can see on http://github.com/jdbeutel/hudson-email-ext/network where I have just updated the master branch.) So that patch probably won't work on the current email-ext.

I don't know when I'll have time to merge those changes. The easiest way to test out what's already here is probably to check out my groovy branch from github, rather than checkout -r31017 of email-ext from svn and apply patch updated_on_2010-05-18.patch.

$ git clone git://github.com/jdbeutel/hudson-email-ext.git
$ cd hudson-email-ext
$ git checkout groovy

Then build with Maven in the normal way for Hudson plugins. (I don't recall off-hand how to do that.)

However, this old version of email-ext with the patch may not be compatible with the current Hudson core. In that case, you would need to merge the new changes from master. The easiest way to get that work back into this JIRA issue may be to fork that repository on github.

I may find that I need to do this myself before too long, in order to add git plugins to my Hudson. In that case, I'll update this JIRA issue.

Hi,

I've performed merge with latest email-ext (whatever was available in David's git repo). Here it is published: http://github.com/svd/hudson-email-ext/

commit diff: http://github.com/svd/hudson-email-ext/commit/f8a1b0e558446202faafdd134884e140ae28cf7c

David, thanks for this patch, I like it!

Updated patch: for latest 2.9-snapshot version

Thanks for updating! It looks good. I'll try it out when I can.

Finally looking at the changes to master just now, I noticed that the new Jelly template seems to provide functionality similar to this patch. I wonder if it would work as well as Groovy. Or, if not, then should this Groovy patch be implemented in a similar way (as a new EmailContent type that loads and evaluates an external file)? Using files that way looks good for shipping multiple ready-made and well-refined choices for template starting points, as well as for tracking changes to template files.

I haven't tried it yet, but one piece of functionality that the new Jelly stuff seems to be missing is the test button. I guess what I did is a kludge, but since the email content templates have gotten this complex, it's crucial to be able to see what they look like on various builds without needing to actually recreate those builds.

Thanks for noting about jelly templates! Just tested - it seems working also
I would like to see groovy support in there also!

Patch for email-ext 2.10 (based on email-ext-groovy-2010-10-07.diff, just a small change in this patch)

I finally pulled svd's update two weeks ago, and it was good.

However, when I tried to update again to the current 2.11-SNAPSHOT, I hit a problem with the new FILE token, because it requires an attribute. This patch tries to pre-render all the tokens (without any attributes), to provide them to the Groovy binding.

I'd like to try redoing this patch along the lines of the new Jelly templates, but with nested content for escaped tokens, instead of putting them in the binding. That should reduce this patch's cross-section and allow for attributes, tokens from Groovy, and templates built out of templates. Hopefully I can find some time this weekend to start.

I submitted code to allow groovy scripting (or scripting with any JSR223 language). This should be in the 2.15 release (when it occurs) as it was pulled into master.

Both jelly templates and groovy scripting are available for creating rich text emails.