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

          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: