Mailext not working with providers: "An attempt to send an e-mail to empty list of recipients, ignored."

Hello,

So, I’m trying to automatically send a mail to developers who broke something.

I thought that this would work by using “culprits” and “developers” but I literally tried all possibilities by this point and it simply does not render the correct list.

The SCM used is GIT and is hosted on BitBucket.

The jenkins version is LTS v2.319.1
The plugin emailext version is v2.86

Pipeline configuration:

post {
        always {
            script {
                notifyBitbucket(buildStatus: currentBuild.result ?: 'SUCCESS')
            }
        }
        failure {
            emailext body: "${currentBuild.currentResult}: Job ${env.JOB_NAME} build ${env.BUILD_NUMBER}\n More info at: ${env.BUILD_URL}",
                recipientProviders: [developers(), upstreamDevelopers(), culprits()],
                subject: "Jenkins Build ${currentBuild.currentResult}: Job ${env.JOB_NAME}",
                attachLog: true
        }
    }

The results (whether I’m using a manually triggered set-up or not):

12:44:46 Sending mail from default account using System Admin e-mail address
12:44:46 messageContentType = text/html; charset=UTF-8
12:44:46 Request made to attach build log
12:44:46 Adding recipients from project recipient list
12:44:46 Collecting change authors…
12:44:46 build: 57
12:44:46 Sending email to upstream committer(s).
12:44:46 Adding recipients from trigger recipient list
12:44:46 Successfully created MimeMessage
12:44:46 An attempt to send an e-mail to empty list of recipients, ignored.

At some point in the documentation ,it states that it needs an e-mail suffix to be set, as it uses the “committer ID” and generates the address based on that + the suffix; but to no avail :frowning:

At this point, I’m at a loss at what I’m doing wrong here. If I set an explicit “to” then the mails do get send! Debug has been enabled but… in this case it does not output a lot of information (in case the mail gets sent then a whole lot of debug data is generated so it does work!)

Any help or insight is welcome at this point

So, good news, I figured out what’s going on. It seems that, for this to work, a changeset needs to be detected by Jenkins, however, while working on PR’s (which are in separate branches), it is not uncommon for me to amend my commit, however, Jenkins does not rehard this as a change (even though the hash changes gor this commit).

Perhaps somebody has a similar use case gor which I am very curious how you worked around this?

For anybody else who missed the base logic of this plugin and who’d like to work with PR and rewriting history… there’s an additional behaviour which can be set in the GIT configuration which allows to “calcultate the changeset” between the branch which is building and another one, for instance “master”. This way, it always tracks the changes correctly (and not compared to the previous build, which in multibranch projects is next to useless).