-
Bug
-
Resolution: Fixed
-
Major
-
None
-
-
2.88
I can't seem to figure out any recipientProviders that contact just a (GitHub) PR's owner/author, in all cases.
In simple cases, where somebody creates a PR and pushes a few patches, developers seems like the right target. But as soon as the PR owner merges with master, that becomes every patch owner in the merge also, correct?
Is there an option I am missing here to achieve what I am looking for?
- duplicates
-
JENKINS-62074 Send build failure email to approver of pull request
-
- Closed
-
- is duplicated by
-
-
- Closed
-
- relates to
-
JENKINS-11759 Allow single user with multiple usernames, therefore allowing same person to be identified
-
- Resolved
-
-
-
- Resolved
-
[JENKINS-62079] No way to email just a PR's owner
Brian J Murrell
added a comment - I am using the github-branch-source plugin with pipelines.
Ultimately the problem is that (AFAICT) the most useful recipientProvider to use with a single PR is:
developers
- Sends email to all the people who caused a change in the change set.
But as I mentioned before that list gets polluted with every author of every patch that was merged from a parent branch when doing a merge to get one's PR up-to-date with it's parent branch.
Brian J Murrell
added a comment - I am using the github-branch-source plugin with pipelines.
Ultimately the problem is that (AFAICT) the most useful recipientProvider to use with a single PR is:
developers
Sends email to all the people who caused a change in the change set.
But as I mentioned before that list gets polluted with every author of every patch that was merged from a parent branch when doing a merge to get one's PR up-to-date with it's parent branch. Correct, it looks through all of the changesets and grabs all the authors.
Kalle Niemitalo
added a comment - The GitHub Branch Source plugin adds a ContributorMetadataAction (javadoc) to the ChangeRequestSCMHead. AFAIK, that represents the owner of the pull request. The plugin attempts to store the email address to the ContributorMetadataAction, but I am not sure the email address is always available from GitHub, with the tightening privacy regulations. Also, the plugin reads the ContributorMetadataAction instance from pullRequestContributorCache and I am not sure the doRetrieve method, which populates this cache, is always called before the ContributorMetadataAction instance is needed.
Anyhow, it seems a RecipientProvider implementation that reads ContributorMetadataAction could be added to email-ext-plugin, and maybe it would work most of the time.
Kalle Niemitalo
added a comment - The GitHub Branch Source plugin adds a ContributorMetadataAction ( javadoc ) to the ChangeRequestSCMHead. AFAIK, that represents the owner of the pull request. The plugin attempts to store the email address to the ContributorMetadataAction, but I am not sure the email address is always available from GitHub, with the tightening privacy regulations. Also, the plugin reads the ContributorMetadataAction instance from pullRequestContributorCache and I am not sure the doRetrieve method, which populates this cache, is always called before the ContributorMetadataAction instance is needed.
Anyhow, it seems a RecipientProvider implementation that reads ContributorMetadataAction could be added to email-ext-plugin, and maybe it would work most of the time. I think the better place for the implementation of the RecipientProvider is in the GitHub Branch Source Plugin. That's the whole point of having a RecipientProvider extension point, so that other plugins can implement providers.
Kalle Niemitalo
added a comment - ContributorMetadataAction is defined in scm-api-plugin, and instantiated by gitlab-branch-source-plugin, p4-plugin, bitbucket-branch-source-plugin, and github-branch-source-plugin. A RecipientProvider implementation that reads ContributorMetadataAction would cover all of these. I don't think github-branch-source-plugin would be a good place for it.
Kalle Niemitalo
added a comment - ContributorMetadataAction is defined in scm-api-plugin, and instantiated by gitlab-branch-source-plugin, p4-plugin, bitbucket-branch-source-plugin, and github-branch-source-plugin. A RecipientProvider implementation that reads ContributorMetadataAction would cover all of these. I don't think github-branch-source-plugin would be a good place for it. Kalle Niemitalo
added a comment - The Email Extension plugin already has a transitive required dependency on the SCM API plugin:
email-ext -> junit-api -> workflow-api -> scm-api
Kalle Niemitalo
added a comment - The Email Extension plugin already has a transitive required dependency on the SCM API plugin:
email-ext -> junit-api -> workflow-api -> scm-api Sorry, I misunderstood your first comment. I agree this should work well.
Basil Crow
added a comment - Fixed in jenkinsci/email-ext-plugin#361 . Released in 2.88 . 
I don't know of any way to identify that from the email-ext plugin perspective. Which plugin are you using for SCM?