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

2 views
Skip to first unread message

jenkins@johnnado.com (JIRA)

unread,
Jan 11, 2017, 8:02:02 PM1/11/17
to jenkinsc...@googlegroups.com
John McGehee commented on Bug JENKINS-24638
 
Re: No E-Mail sent when build of new branch fails for first time

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. 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.

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.

Add Comment Add Comment
 
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
Atlassian logo

dbeck@cloudbees.com (JIRA)

unread,
Jan 12, 2017, 3:26:02 AM1/12/17
to jenkinsc...@googlegroups.com

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. Stephen Connolly?

jenkins@johnnado.com (JIRA)

unread,
Jan 12, 2017, 2:49:02 PM1/12/17
to jenkinsc...@googlegroups.com
John McGehee edited a comment on Bug JENKINS-24638
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|https://jenkins.io/blog/2016/07/18/pipline-notifications/].  As part of my experiments, I used all the recipient providers I know:

{code}     def recipients = [[$class: 'CulpritsRecipientProvider'],

                     [$class: 'UpstreamComitterRecipientProvider'],
                     [$class: 'RequesterRecipientProvider'],
                     [$class: 'DevelopersRecipientProvider'],
                     [$class: 'FailingTestSuspectsRecipientProvider'],
                     [$class: 'FirstFailingBuildSuspectsRecipientProvider']]{code}

I tried two scenarios.

h3. 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:
{code}git checkout -b notifybuild4
git push --set-upstream origin notifybuild4{code}

Jenkins built this new branch and failed as expected, but no email was sent, because the providers yielded no recipients:
bq. 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)

h3. 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:
{code}git checkout -b notifybuild5

atom Jenkinsfile    # Add an empty line
git add Jenkinsfile
git commit
git push --set-upstream origin notifybuild5{code}


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}}:
bq. 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)

slide.o.mix@gmail.com (JIRA)

unread,
Jan 12, 2017, 2:52:02 PM1/12/17
to jenkinsc...@googlegroups.com

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

jenkins@johnnado.com (JIRA)

unread,
Jan 12, 2017, 2:52:02 PM1/12/17
to jenkinsc...@googlegroups.com

David Bottger, 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.

jenkins@johnnado.com (JIRA)

unread,
Jan 12, 2017, 2:53:01 PM1/12/17
to jenkinsc...@googlegroups.com
John McGehee edited a comment on Bug JENKINS-24638
[~ db 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.

stephen.alan.connolly@gmail.com (JIRA)

unread,
Feb 3, 2017, 6:44:03 AM2/3/17
to jenkinsc...@googlegroups.com

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.org (JIRA)

unread,
Feb 1, 2019, 4:32:03 PM2/1/19
to jenkinsc...@googlegroups.com

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?

 

This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)

me@vitalykarasik.com (JIRA)

unread,
Feb 20, 2019, 7:43:03 AM2/20/19
to jenkinsc...@googlegroups.com

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.

dbeck@cloudbees.com (JIRA)

unread,
Feb 20, 2019, 8:40:02 AM2/20/19
to jenkinsc...@googlegroups.com

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.

me@vitalykarasik.com (JIRA)

unread,
Feb 20, 2019, 9:24:02 AM2/20/19
to jenkinsc...@googlegroups.com

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

6081986@gmail.com (JIRA)

unread,
Apr 28, 2020, 8:32:04 AM4/28/20
to jenkinsc...@googlegroups.com

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.

This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)
Atlassian logo
Reply all
Reply to author
Forward
0 new messages