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

Option to disable svn:externals being used when calculating email recipients on build failure

    • Icon: Improvement Improvement
    • Resolution: Unresolved
    • Icon: Major Major
    • subversion-plugin
    • None
    • Platform: All, OS: All

      I would like to have an option to not follow svn:externals when calculating the
      email recipient list when a build fails. The reason is that we bring in a
      substantial amount of source code into our builds from other teams and when our
      build fails, no mail should be sent to people outside of our team.

          [JENKINS-3792] Option to disable svn:externals being used when calculating email recipients on build failure

          kutzi added a comment -

          Sounds more like a subversion plugin than a mail issue to me.

          And BTW: for me this sounds more like a configuration problem: if you don't want the code of the other teams to be treated as a normal part of your source tree, than svn:externals are probably not the best option.
          I would propose to include them as pre-build binaries o.s.l.t.

          kutzi added a comment - Sounds more like a subversion plugin than a mail issue to me. And BTW: for me this sounds more like a configuration problem: if you don't want the code of the other teams to be treated as a normal part of your source tree, than svn:externals are probably not the best option. I would propose to include them as pre-build binaries o.s.l.t.

          kutzi added a comment -

          Doesn't make sense to do this IMHO. Please reopen, if you have good reasons why this should be implemented

          kutzi added a comment - Doesn't make sense to do this IMHO. Please reopen, if you have good reasons why this should be implemented

          jesperes added a comment -

          I disagree.

          There are arguments for and against our way of using svn:externals, but frankly I don't think it is Jenkins' job to have an opinion about it. For the most part Jenkins/Hudson stays out of my way and lets me do my job, but I don't want a butler who keeps telling me that I have to read the comics in a certain order.

          Without this feature, Jenkins will be sending mail to people who do not want them (i.e. spam), and there is nothing we can to do change that without severely crippling other features.

          If this is a matter of "good feature, please provide a patch" I may consider contributing it myself.

          jesperes added a comment - I disagree. There are arguments for and against our way of using svn:externals, but frankly I don't think it is Jenkins' job to have an opinion about it. For the most part Jenkins/Hudson stays out of my way and lets me do my job, but I don't want a butler who keeps telling me that I have to read the comics in a certain order. Without this feature, Jenkins will be sending mail to people who do not want them (i.e. spam), and there is nothing we can to do change that without severely crippling other features. If this is a matter of "good feature, please provide a patch" I may consider contributing it myself.

          kutzi added a comment -

          You could change the e-mail addresses of the people from the other teams to go to some junk mail address

          kutzi added a comment - You could change the e-mail addresses of the people from the other teams to go to some junk mail address

          jesperes added a comment -

          That would be difficult, since the mail address is computed from the Subversion user name.

          jesperes added a comment - That would be difficult, since the mail address is computed from the Subversion user name.

          kutzi added a comment -

          You can overwrite the e-mail address in Jenkins' user pages

          kutzi added a comment - You can overwrite the e-mail address in Jenkins' user pages

          seanm added a comment -

          actually you can't.

          if you specify the list of recipients in the project configuration, any people who commit to any repository you have linked via externals, are added to your own installation (Listed under the 'People' section of Jenkins), and also are e-mailed when commits to externals break our internal apps build process.

          IMO, the list of people e-mailed when a build is broken should only be based on what is CONFIGURED, not what the Subversion SCM plugin decides based on a commit log, here you have software assuming behaviour on behalf of the user, it should be at minimum a configurable option "Please do not append to the list of e-mail notification recipients"

          seanm added a comment - actually you can't. if you specify the list of recipients in the project configuration, any people who commit to any repository you have linked via externals, are added to your own installation (Listed under the 'People' section of Jenkins), and also are e-mailed when commits to externals break our internal apps build process. IMO, the list of people e-mailed when a build is broken should only be based on what is CONFIGURED, not what the Subversion SCM plugin decides based on a commit log, here you have software assuming behaviour on behalf of the user, it should be at minimum a configurable option "Please do not append to the list of e-mail notification recipients"

          seanm added a comment -

          Currently our Jenkins 'People' page has about 20 user id's in there which by rights should not be included in our internal build server - but you say that is the correct/intended behaviour?

          For public projects perhaps

          For internal/private build servers, I would argue no.

          seanm added a comment - Currently our Jenkins 'People' page has about 20 user id's in there which by rights should not be included in our internal build server - but you say that is the correct/intended behaviour? For public projects perhaps For internal/private build servers, I would argue no.

            Unassigned Unassigned
            jesperes jesperes
            Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated: