Issue with current broken build email notifications is that people not related to braking product build also get emails and naturally consider them as spam. This situation compromises email notifications being significant part of CI.
      In my case product is combined of shared components and put together using subversion externals. In fact this subdivision can act as a hint narrowing commiter set responsible for breaking build.

      Requirements:
      Warnings plugin should return source file path which broke project build.

      My suggestion:
      Step 1. Get source file path that broke the build.
      Step 2. Using subversion get svn:external under which broken source file is located.
      Step 3. Get change commiters from previous stable build who commited to appropriate external from Step 2.
      Step 4. Email notifications of broken builds to commiters from Step 3.

      P.S. Other ideas on how to narrow notification receiver set would be interesting to read.

          [JENKINS-8202] Smarter broken build email notification

          kutzi added a comment -

          IMO it's generally not possible to determine which exact file broke the build without re-implementing the exact compiler behaviour (for all supported compiler types!) in Jenkins.
          So I'm not sure how one should implement your suggestion.

          kutzi added a comment - IMO it's generally not possible to determine which exact file broke the build without re-implementing the exact compiler behaviour (for all supported compiler types!) in Jenkins. So I'm not sure how one should implement your suggestion.

          kutzi added a comment -

          Please reopen if you've suggestions how to implement this feature

          kutzi added a comment - Please reopen if you've suggestions how to implement this feature

          aleksas added a comment -

          This is a slightly different but more general approach:
          Partly implementation of Jenkins Continuous Integration game plugin can be used. Since it copes with list of users who made changes since last build.

          Like Continuous Integration game this plugin could keep a list of versioning system users. In addition to that this list would keep repository paths user is responsible for. Repository path list for each user would be manageable from Jenkins UI.

          The biggest issue is probably resolving faulty file path that caused build to fail.

          aleksas added a comment - This is a slightly different but more general approach: Partly implementation of Jenkins Continuous Integration game plugin can be used. Since it copes with list of users who made changes since last build. Like Continuous Integration game this plugin could keep a list of versioning system users. In addition to that this list would keep repository paths user is responsible for. Repository path list for each user would be manageable from Jenkins UI. The biggest issue is probably resolving faulty file path that caused build to fail.

          kutzi added a comment -

          Sorry, but I cannot see any principal change to your previous suggestion. We have still the problem that it's generally not possible to determine the true culprit unless we reimplement the compiler/linker logic.

          Imagine someone changes an interface in repository path A, but doesn't change the implementation in path B.
          Now becuase the build fails in path B, someone which would at the same time commit a completely unrelated (and perfectly valid) change to path B would be determined as the culprit?

          kutzi added a comment - Sorry, but I cannot see any principal change to your previous suggestion. We have still the problem that it's generally not possible to determine the true culprit unless we reimplement the compiler/linker logic. Imagine someone changes an interface in repository path A, but doesn't change the implementation in path B. Now becuase the build fails in path B, someone which would at the same time commit a completely unrelated (and perfectly valid) change to path B would be determined as the culprit?

          aleksas added a comment -

          Yes. As I see it person committing implementation to path B would have to update his code anyway. In fact people changing interfaces (case A) are likely to be architects who sometimes do not bother developing all interface implementations. In this case change B should be seen as the culprit.

          Other example of the same situation is if we have a 3rd party component stored in totally different repository (different organization). It is even impossible to notify developer that changed code in remote repository. Developer from local repository should be the one to be notified.

          In this case it would be up to "implementation developer" to notify person who committed interface change if it was faulty.

          More over since we'd have a list of paths it could also act as repository sub-divider. That is after build was broken only person responsible for that path and users that made commits to that path would be notified.

          aleksas added a comment - Yes. As I see it person committing implementation to path B would have to update his code anyway. In fact people changing interfaces (case A) are likely to be architects who sometimes do not bother developing all interface implementations. In this case change B should be seen as the culprit. Other example of the same situation is if we have a 3rd party component stored in totally different repository (different organization). It is even impossible to notify developer that changed code in remote repository. Developer from local repository should be the one to be notified. In this case it would be up to "implementation developer" to notify person who committed interface change if it was faulty. More over since we'd have a list of paths it could also act as repository sub-divider. That is after build was broken only person responsible for that path and users that made commits to that path would be notified.

          kutzi added a comment -

          Sorry, but the scenario you describe may be true for your organization, but is IMHO not true for the majority of users - it's certainly not true for the organization I work in.

          If you're in need of this feature, IMO the best way would be to implement it as a plugin. If you then come up with specific suggestions of how Jenkins core could offer extension points which help you implement that feature, you're welcome to suggest them here or on the developer list.

          kutzi added a comment - Sorry, but the scenario you describe may be true for your organization, but is IMHO not true for the majority of users - it's certainly not true for the organization I work in. If you're in need of this feature, IMO the best way would be to implement it as a plugin. If you then come up with specific suggestions of how Jenkins core could offer extension points which help you implement that feature, you're welcome to suggest them here or on the developer list.

          Garen Parham added a comment -

          The solution I've typically seen is that the email is sent to N number of users where the content of the email includes a blame/annotate list along with a summary of changes; those two items allows people who likely did cause a problem to investigate.

          With mercurial and git, an additional step I've also seen on a failing build is to then kickoff builds driven by the bisect sub-command, which searches for the changes that caused the failure (or first successful one) and add that info to the content of the email ("Changeset <abc123...> caused build to fail. Changeset <abc123...> contains the following changes: <list of files / short diffs / checkin comments here>")

          The blame/annotate/bisect features are of course dependent on the particular version control system.

          Garen Parham added a comment - The solution I've typically seen is that the email is sent to N number of users where the content of the email includes a blame/annotate list along with a summary of changes; those two items allows people who likely did cause a problem to investigate. With mercurial and git, an additional step I've also seen on a failing build is to then kickoff builds driven by the bisect sub-command, which searches for the changes that caused the failure (or first successful one) and add that info to the content of the email ("Changeset <abc123...> caused build to fail. Changeset <abc123...> contains the following changes: <list of files / short diffs / checkin comments here>") The blame/annotate/bisect features are of course dependent on the particular version control system.

          Oleg Nenashev added a comment -

          Nobody has taken the feature request, no votes

          Oleg Nenashev added a comment - Nobody has taken the feature request, no votes

            Unassigned Unassigned
            aleksas aleksas
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: