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

Add support for the Claim Plugin

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      It would be great if this plugin could add support for the Claim Plugin (https://wiki.jenkins-ci.org/display/JENKINS/Claim+plugin, 1800 installations).

      I imagine two additional features shown to the user in the Project configuration, if the Claim Plugin is installed:

      • A "recipient group" called "Claimer" or something so that we can select when this person gets an email.
      • One or more triggers related to a failed build which is already claimed. Maybe it could be a checkbox to the existing triggers ("...and is already claimed")

      The end result would be that the user can configure that for example only the owners and the claimer (i.e. not the other culprits) will be emailed when a build with a sticky Claim fails again.

        Attachments

          Issue Links

            Activity

            Hide
            slide_o_mix Alex Earl added a comment -

            When using a script in the recipient list, your last line of the script must be a string with comma separated addresses.

            def committers = []
            // loop through and grab committers from somewhere cool
            // here comes the last line
            committers.unique().join(',')
            

            When trying to do content (body) you want to create a template, not a script.
            ${SCRIPT, template="output-claim-info.template"}

            Did you try this?

            import hudson.tasks.Mailer.UserProperty
            
            address = user.getProperty(hudson.tasks.Mailer.UserProperty.class).address
            

            You can definitely provide default recipients, just do something like this:

            Project Recipient List: someone@somewhere.com, ${SCRIPT, script="get-claim-recipient.groovy"}

            Show
            slide_o_mix Alex Earl added a comment - When using a script in the recipient list, your last line of the script must be a string with comma separated addresses. def committers = [] // loop through and grab committers from somewhere cool // here comes the last line committers.unique().join( ',' ) When trying to do content (body) you want to create a template, not a script. ${SCRIPT, template="output-claim-info.template"} Did you try this? import hudson.tasks.Mailer.UserProperty address = user.getProperty(hudson.tasks.Mailer.UserProperty.class).address You can definitely provide default recipients, just do something like this: Project Recipient List: someone@somewhere.com, ${SCRIPT, script="get-claim-recipient.groovy"}
            Hide
            mabahj Markus added a comment -

            Thank you again. After a lot of trial and errors, the UserProperty problem was resolved: The class exists on the Jenkins production server, not on my simple test server. I guess it is because my test server only has the AD plugin installed but it does not use it. It uses Jenkins's own user database. Also, then "last line" trick did the trick.

            But I've realized, now that this works, that I have to do this as a pre-mail script. I'd like to replace the default recipients and I'd like it not to email the Culprits and Committers if the job is claimed. So I have to edit the complete recipients list just before the mail is sent, which is a pre-send script. I'll guess I'll have to do some scripting to distribute the pre-send script to all the jobs until we can add global pre-mail scripts (JENKINS-14508).

            Here's what I ended up with, for future googlers. I kept the array in case I'd like to add more recipients from other sources later.

            def committers = []
            
            build.actions.each { action ->
            if(action.class.name == "hudson.plugins.claim.ClaimBuildAction" && action.isClaimed()) {
              hudson.model.User user = hudson.model.User.get(action.getClaimedBy());  
              address = user.getProperty(hudson.tasks.Mailer.UserProperty.class).address  
              committers[0]=address
            }
            }
            
            // here comes the last line, it MUST be the last line for this to work!!
            committers.unique().join(',')
            

            I'd still like a built-in support for the Claim plugin, which was the initial request, so I'd prefer to leave this as open. But I'll accept a Won't Fix if you prefer that such things are resolved using the (excellent) scripting features.

            Show
            mabahj Markus added a comment - Thank you again. After a lot of trial and errors, the UserProperty problem was resolved: The class exists on the Jenkins production server, not on my simple test server. I guess it is because my test server only has the AD plugin installed but it does not use it. It uses Jenkins's own user database. Also, then "last line" trick did the trick. But I've realized, now that this works, that I have to do this as a pre-mail script. I'd like to replace the default recipients and I'd like it not to email the Culprits and Committers if the job is claimed. So I have to edit the complete recipients list just before the mail is sent, which is a pre-send script. I'll guess I'll have to do some scripting to distribute the pre-send script to all the jobs until we can add global pre-mail scripts ( JENKINS-14508 ). Here's what I ended up with, for future googlers. I kept the array in case I'd like to add more recipients from other sources later. def committers = [] build.actions.each { action -> if (action. class. name == "hudson.plugins.claim.ClaimBuildAction" && action.isClaimed()) { hudson.model.User user = hudson.model.User.get(action.getClaimedBy()); address = user.getProperty(hudson.tasks.Mailer.UserProperty.class).address committers[0]=address } } // here comes the last line, it MUST be the last line for this to work!! committers.unique().join( ',' ) I'd still like a built-in support for the Claim plugin, which was the initial request, so I'd prefer to leave this as open. But I'll accept a Won't Fix if you prefer that such things are resolved using the (excellent) scripting features.
            Hide
            slide_o_mix Alex Earl added a comment -

            I think that in the future I'll make two extension points available

            1) Recipient list, which can override the other recipient categories similar to how the triggers can override other triggers. This would make it so that the Claim plugin could implement their own recipient category if they wanted to.
            2) I am already working on making the triggers into a better model of the extension point mechanism so that other plugins or code could cause triggers to occur.

            I am also adding a ScriptTrigger and PreBuildScriptTrigger so that you could script your own triggers. Would these meet your needs? Basically the idea would be to empower other plugins to implement features like this so that the dependencies of email-ext don't grow exponentially with each plugin that people would like to have support for.

            Show
            slide_o_mix Alex Earl added a comment - I think that in the future I'll make two extension points available 1) Recipient list, which can override the other recipient categories similar to how the triggers can override other triggers. This would make it so that the Claim plugin could implement their own recipient category if they wanted to. 2) I am already working on making the triggers into a better model of the extension point mechanism so that other plugins or code could cause triggers to occur. I am also adding a ScriptTrigger and PreBuildScriptTrigger so that you could script your own triggers. Would these meet your needs? Basically the idea would be to empower other plugins to implement features like this so that the dependencies of email-ext don't grow exponentially with each plugin that people would like to have support for.
            Hide
            mabahj Markus added a comment -

            You're right. You cannot customize support for every plugin for everyone. I don't fully understand how your planned features will be, but I understand the basic ideas and I think they will meet my needs.

            Show
            mabahj Markus added a comment - You're right. You cannot customize support for every plugin for everyone. I don't fully understand how your planned features will be, but I understand the basic ideas and I think they will meet my needs.
            Hide
            slide_o_mix Alex Earl added a comment -

            Added the script triggers that allow you to define your own custom logic for when an email should be triggered (2.28)

            Added default pre-send script (2.29)

            Show
            slide_o_mix Alex Earl added a comment - Added the script triggers that allow you to define your own custom logic for when an email should be triggered (2.28) Added default pre-send script (2.29)

              People

              • Assignee:
                slide_o_mix Alex Earl
                Reporter:
                mabahj Markus
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: