• Icon: Improvement Improvement
    • Resolution: Fixed
    • Icon: Major Major
    • email-ext-plugin
    • None
    • Platform: All, OS: All

      We migrated from CruiseControl to Hudson recently and found that it is not able
      to send Rich text email. I checked the Email-Extender plugin but the variables
      provided by it are limiting.

      So I modified the plugin to use Groovy SimpleTemplate to generate the email
      content. A user would set the email content in form of Groovy script through UI.
      To the script the build variable would be exposed as a binding

      Using that one can extract whatever information he is interested in and then
      output it in required form

        1. another_fix_2010-02-19.patch
          36 kB
        2. based_on_2009-09-28.patch
          29 kB
        3. email-ext-groovy-2010-10-07.diff
          41 kB
        4. email-ext-groovy-2011-02-16.patch
          41 kB
        5. fixed_tests_2010-02-12.patch
          36 kB
        6. groovy-email.patch
          8 kB
        7. groovy-email2.patch
          8 kB
        8. html.br.patch
          1.0 kB
        9. html-email.txt
          16 kB
        10. subject-template.txt
          0.1 kB
        11. svn-template.html
          6 kB
        12. svn-template.html
          6 kB
        13. updated_on_2010-02-12.patch
          31 kB
        14. updated_on_2010-05-07.patch
          37 kB
        15. updated_on_2010-05-18.patch
          37 kB

          [JENKINS-2175] Sending Rich text mail with Hudson

          mcrooney added a comment -

          This looks really wonderful, what is the easiest way to test it out? Should I apply a patch to the email-ext plugin and if so, which patch? Thanks so much!

          mcrooney added a comment - This looks really wonderful, what is the easiest way to test it out? Should I apply a patch to the email-ext plugin and if so, which patch? Thanks so much!

          J. David Beutel added a comment - - edited

          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.

          J. David Beutel added a comment - - edited 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.

          svd added a comment -

          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!

          svd added a comment - 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!

          svd added a comment -

          Updated patch: for latest 2.9-snapshot version

          svd added a comment - 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.

          J. David Beutel added a comment - 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.

          svd added a comment -

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

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

          vjuranek added a comment -

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

          vjuranek added a comment - 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.

          J. David Beutel added a comment - 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.

          Alex Earl added a comment -

          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.

          Alex Earl added a comment - 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.

          Alex Earl added a comment -

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

          Alex Earl added a comment - Both jelly templates and groovy scripting are available for creating rich text emails.

            slide_o_mix Alex Earl
            chetan_oct chetan_oct
            Votes:
            42 Vote for this issue
            Watchers:
            22 Start watching this issue

              Created:
              Updated:
              Resolved: