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

No E-Mail sent when build of new branch fails for first time

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • git-plugin
    • None
    • Email-ext 2.38.1, Jenkins 1.575

      Steps to reproduce my problem:

      1. Using GIT for SCM and Jenkins is set up to trigger build on SCM change
      2. Master branch is building fine and all tests are passing
      3. Create new branch from master
      4. Break something so build fails and push to the new branch
      5. Build is triggered in Jenkins by SCM change (but it says "No changes")

      Expected result is that email-ext plugin sends notification of build failure to the person who first pushed to the new branch. But actually no e-mail is sent and the log says:

      Email was triggered for: Failure - Any
      Sending email for trigger: Failure - Any
      An attempt to send an e-mail to empty list of recipients, ignored.
      Finished: FAILURE
      

      The "Failure - Any" trigger has Developers and Culprits set under "Send To". When a second commit is made to the new branch by the same person, the trigger works fine - it finds the e-mail address of the culprit and sends the e-mail.

          [JENKINS-24638] No E-Mail sent when build of new branch fails for first time

          Alex Earl added a comment -

          If Jenkins says "no changes" then email-ext will also see no changes and there won't be developers or culprits. This sounds like an issue in either core or git scm.

          Alex Earl added a comment - If Jenkins says "no changes" then email-ext will also see no changes and there won't be developers or culprits. This sounds like an issue in either core or git scm.

          Alex Earl added a comment -

          If the build doesn't see any changes, then email-ext won't see them either. This needs to be addressed in the SCM.

          Alex Earl added a comment - If the build doesn't see any changes, then email-ext won't see them either. This needs to be addressed in the SCM.

          Daniel Beck added a comment -

          The obvious workaround of course is to trigger the first build immediately after branch creation, so there's a reference point for the first failing build's changelog to compare to.

          Daniel Beck added a comment - The obvious workaround of course is to trigger the first build immediately after branch creation, so there's a reference point for the first failing build's changelog to compare to.

          John McGehee added a comment - - edited

          I encountered this same issue with Jenkins 2.19.2, and email-ext 2.52. I did some further experiments, and my results contradict some of the previous comments.

          I am running email-ext as described in Sending Notifications in Pipeline. As part of my experiments, I used all the recipient providers I know:

               def recipients = [[$class: 'CulpritsRecipientProvider'],
                                [$class: 'UpstreamComitterRecipientProvider'],
                                [$class: 'RequesterRecipientProvider'],
                                [$class: 'DevelopersRecipientProvider'],
                                [$class: 'FailingTestSuspectsRecipientProvider'],
                                [$class: 'FirstFailingBuildSuspectsRecipientProvider']]

          I tried two scenarios.

          Push without modification

          I started with a branch into which I had purposely introduced a failure. When Jenkins builds this failing branch, it sends a notification email.

          I created a new branch, and pushed it without modification:

          git checkout -b notifybuild4
          git push --set-upstream origin notifybuild4

          Jenkins built this new branch and failed as expected, but no email was sent, because the providers yielded no recipients:

          An attempt to send an e-mail to empty list of recipients, ignored.

          Building branch notifybuild4 a second time resulted in an email being sent.

          I expected the recipient providers to yield the same email addresses in all these situations:

          • When the original branch was built (this works)
          • When branch notifybuild4 was first pushed (this does not work)
          • When branch notifybuild4 was re-built (this works)

          Push with modification

          Starting with branch notifybuild4 (which fails as described above), I created a new branch, made an immaterial change and and pushed it:

          git checkout -b notifybuild5
          atom Jenkinsfile    # Add an empty line
          git add Jenkinsfile 
          git commit
          git push --set-upstream origin notifybuild5

          Once again, Jenkins' build of this new branch failed as expected, but no email was sent, because the providers yielded no recipients according to the console output from email-ext:

          An attempt to send an e-mail to empty list of recipients, ignored.

          Building branch notifybuild5 a second time resulted in an email being sent.

          I expected the recipient providers to yield the same email addresses in all these situations:

          • When branch notifybuild4 was rebuilt (this works)
          • When branch notifybuild5 was first pushed (this does not work)
          • When branch notifybuild5 was re-built (this works)

          John McGehee added a comment - - edited I encountered this same issue with Jenkins 2.19.2, and email-ext 2.52. I did some further experiments, and my results contradict some of the previous comments. I am running email-ext as described in Sending Notifications in Pipeline . As part of my experiments, I used all the recipient providers I know: def recipients = [[$class: 'CulpritsRecipientProvider' ], [$class: 'UpstreamComitterRecipientProvider' ], [$class: 'RequesterRecipientProvider' ], [$class: 'DevelopersRecipientProvider' ], [$class: 'FailingTestSuspectsRecipientProvider' ], [$class: 'FirstFailingBuildSuspectsRecipientProvider' ]] I tried two scenarios. Push without modification I started with a branch into which I had purposely introduced a failure. When Jenkins builds this failing branch, it sends a notification email. I created a new branch, and pushed it without modification: git checkout -b notifybuild4 git push --set-upstream origin notifybuild4 Jenkins built this new branch and failed as expected, but no email was sent, because the providers yielded no recipients: An attempt to send an e-mail to empty list of recipients, ignored. Building branch notifybuild4 a second time resulted in an email being sent. I expected the recipient providers to yield the same email addresses in all these situations: When the original branch was built (this works) When branch notifybuild4 was first pushed (this does not work) When branch notifybuild4 was re-built (this works) Push with modification Starting with branch notifybuild4 (which fails as described above), I created a new branch, made an immaterial change and and pushed it: git checkout -b notifybuild5 atom Jenkinsfile # Add an empty line git add Jenkinsfile git commit git push --set-upstream origin notifybuild5 Once again, Jenkins' build of this new branch failed as expected, but no email was sent, because the providers yielded no recipients according to the console output from email-ext : An attempt to send an e-mail to empty list of recipients, ignored. Building branch notifybuild5 a second time resulted in an email being sent. I expected the recipient providers to yield the same email addresses in all these situations: When branch notifybuild4 was rebuilt (this works) When branch notifybuild5 was first pushed (this does not work) When branch notifybuild5 was re-built (this works)

          Daniel Beck added a comment -

          I started with a branch into which I had purposely introduced a failure. I created a new branch, and pushed it without modification

          The idea I mentioned was to create the branch from a master/trunk that builds successfully, so the first build of the branch is identical to master/trunk, and only then introduce changes that could break things.

          As there's no previous build for the branch, Jenkins has nothing to compare it to to determine who should be emailed. The developer of the last commit? May not be the culprit if there's several changes pushed. Everyone in the history of the branch? Too many false positives.

          It would be nice if there were metadata from e.g. comparing the branch to master/trunk, but that's SCM specific. Not sure whether SCM API could do that, and whether the email plugins could take that into account. stephenconnolly?

          Daniel Beck added a comment - I started with a branch into which I had purposely introduced a failure. I created a new branch, and pushed it without modification The idea I mentioned was to create the branch from a master/trunk that builds successfully, so the first build of the branch is identical to master/trunk, and only then introduce changes that could break things. As there's no previous build for the branch, Jenkins has nothing to compare it to to determine who should be emailed. The developer of the last commit? May not be the culprit if there's several changes pushed. Everyone in the history of the branch? Too many false positives. It would be nice if there were metadata from e.g. comparing the branch to master/trunk, but that's SCM specific. Not sure whether SCM API could do that, and whether the email plugins could take that into account. stephenconnolly ?

          Alex Earl added a comment -

          Git will see the branch and tell email-ext there were no changes.

          Alex Earl added a comment - Git will see the branch and tell email-ext there were no changes.

          John McGehee added a comment - - edited

          danielbeck, I completely understand your dilemma. I modified my 11 Jan comment to explain the behavior I expected.

          It is nice to hear from you. I recall fondly our conversations at Jenkins World 2015 and 2016.

          John McGehee added a comment - - edited danielbeck , I completely understand your dilemma. I modified my 11 Jan comment to explain the behavior I expected. It is nice to hear from you. I recall fondly our conversations at Jenkins World 2015 and 2016.

          It would be nice if there were metadata from e.g. comparing the branch to master/trunk, but that's SCM specific. Not sure whether SCM API could do that, and whether the email plugins could take that into account.

          There is the APIs to enable that discovery of changes. We will likely modify the Branch API plugin in the future to provide a link to the branch that a PR is targeting on the changelog... but that may require supporting core changes to handle the fact that a PR's target branch can be changed.

          Stephen Connolly added a comment - It would be nice if there were metadata from e.g. comparing the branch to master/trunk, but that's SCM specific. Not sure whether SCM API could do that, and whether the email plugins could take that into account. There is the APIs to enable that discovery of changes. We will likely modify the Branch API plugin in the future to provide a link to the branch that a PR is targeting on the changelog... but that may require supporting core changes to handle the fact that a PR's target branch can be changed.

          Jim Tilander added a comment -

          I believe I'm still running into this bug as of today with Jenkins 2.161 and git plugin 3.9.3. Any progress on this issue or is it effectively dead? This pretty much makes culprit emails not work in a PR workflow, and you are forced to email a well known email group instead which is less than ideal. Or have I missed some development?

           

          Jim Tilander added a comment - I believe I'm still running into this bug as of today with Jenkins 2.161 and git plugin 3.9.3. Any progress on this issue or is it effectively dead? This pretty much makes culprit emails not work in a PR workflow, and you are forced to email a well known email group instead which is less than ideal. Or have I missed some development?  

          Agree with Jim - it seems really weird that such important bug with (IMHO) simple fix is still open.

          I understand that in the first build there is no information about changes, but 'RequesterRecipientProvider' IMHO should "Sends email to the user who initiated the build"  exactly as its help says.

          Vitaly Karasik added a comment - Agree with Jim - it seems really weird that such important bug with (IMHO) simple fix is still open. I understand that in the first build there is no information about changes, but 'RequesterRecipientProvider' IMHO should "Sends email to the user who initiated the build"  exactly as its help says.

          Daniel Beck added a comment -

          RequesterRecipientProvider' IMHO should "Sends email to the user who initiated the build" exactly as its help says

          To clarify, requester is the user who clicked "Build Now", not the Git username/email addresses associated with the commits. Is someone manually starting builds and this does not work? If so, that would be a separate bug.

          Daniel Beck added a comment - RequesterRecipientProvider' IMHO should "Sends email to the user who initiated the build" exactly as its help says To clarify, requester is the user who clicked "Build Now", not the Git username/email addresses associated with the commits. Is someone manually starting builds and this does not work? If so, that would be a separate bug.

          Daniel - thanks you, got it. 
          So it's not related.

          Vitaly Karasik added a comment - Daniel - thanks you, got it.  So it's not related.

          Dmitrii Lapin added a comment -

          Same problem on SVN. Is there any provider which can send email to "developer, who created branch"?

          Sometimes branches can be copied from unstable trunk and developer shoud see results of all builds.

          Dmitrii Lapin added a comment - Same problem on SVN. Is there any provider which can send email to "developer, who created branch"? Sometimes branches can be copied from unstable trunk and developer shoud see results of all builds.

          Mark Waite added a comment -

          dm_lapin there isn't really a concept of "developer who created the branch" in git. Other SCM systems may have that concept, but git does not.

          Mark Waite added a comment - dm_lapin there isn't really a concept of "developer who created the branch" in git. Other SCM systems may have that concept, but git does not.

          Git has the concept of a commit author and a committer, which is a step up from subversion (which just has the committer).

          That addresses the actual commits. But a branch is created by pushing commits to the branch.

          A branch in Git is just a pointer to a commit. The branch itself does not store details of who pushed the pointer.

          Now while 8 or 9 times out of 10 the person who committed the head commit of the branch is the person who created the branch, but there is a significant number of cases where the committer doesn't actually create the PR. Thus we cannot assume that the committer of the head commit of the first build created the branch.

          If you have your own git server, you can install hooks to capture the identity of the branch pusher.

          If you are using GitHub then you could use the GitHub API to get the user who created a PR, but the generic Git plugin cannot assume it is building github... even if the URL says `github.com` as there are some people who run their Jenkins in a DMZ and have mirrored their github.com hosted content into an internal git repo and inject a DNS entry into their Jenkins DMZ so that requests for github.com are served by their internal git repo.

          The next issue - at least for git - is determining which commit(s) are the delta from which the branch was created. It is only convention that a branch gets its name. In fact you can have a case where the PR head commit by itself would build, but by the time it is built, it fails because the interaction with the latest commit on the target branch causes the break. Who should get the blame for that broken first build? What changes were in that build? Are the changes in master since the PR branch was created in the build? Are the commits in the PR branch itself? At first glance the answer to both is yes, but the implications of that yes are a less clear

          Stephen Connolly added a comment - Git has the concept of a commit author and a committer, which is a step up from subversion (which just has the committer). That addresses the actual commits. But a branch is created by pushing commits to the branch. A branch in Git is just a pointer to a commit. The branch itself does not store details of who pushed the pointer. Now while 8 or 9 times out of 10 the person who committed the head commit of the branch is the person who created the branch, but there is a significant number of cases where the committer doesn't actually create the PR. Thus we cannot assume that the committer of the head commit of the first build created the branch. If you have your own git server, you can install hooks to capture the identity of the branch pusher. If you are using GitHub then you could use the GitHub API to get the user who created a PR, but the generic Git plugin cannot assume it is building github... even if the URL says `github.com` as there are some people who run their Jenkins in a DMZ and have mirrored their github.com hosted content into an internal git repo and inject a DNS entry into their Jenkins DMZ so that requests for github.com are served by their internal git repo. The next issue - at least for git - is determining which commit(s) are the delta from which the branch was created. It is only convention that a branch gets its name. In fact you can have a case where the PR head commit by itself would build, but by the time it is built, it fails because the interaction with the latest commit on the target branch causes the break. Who should get the blame for that broken first build? What changes were in that build? Are the changes in master since the PR branch was created in the build? Are the commits in the PR branch itself? At first glance the answer to both is yes, but the implications of that yes are a less clear

          For this specific case, on the first build of a branch, it does make sense to assume that the one that needs to be notified is the author (or the committer) of the head.

          Sure, you might come up with scenarios when this is not the case, but allow the person that wrote the code to at least know that something went wrong.

          Doing nothing is the worst option here.

          Torbjörn Axelsson added a comment - For this specific case, on the first build of a branch, it does make sense to assume that the one that needs to be notified is the author (or the committer) of the head. Sure, you might come up with scenarios when this is not the case, but allow the person that wrote the code to at least know that something went wrong. Doing nothing is the worst option here.

          kpop added a comment -

          This issue also occurs with Mercurial.

          kpop added a comment - This issue also occurs with Mercurial.

            Unassigned Unassigned
            kaupo Kaupo Kuresson
            Votes:
            11 Vote for this issue
            Watchers:
            15 Start watching this issue

              Created:
              Updated: