Exclude individual pull request commits from notification emails
We have a notification email going out to our entire team once a night when the official build is done, which lists all the changes that were made.
When pull requests are merged, is there a way to have the email just list the pull request that was merged, without listing out every commit that was a part of the pull request?
Please sign in to leave a comment.
Hi,
Could you confirm whether you are using the pull requests plugin or just adding the pull requests branches to the specification manually? If it's the former and it's not happening, we could try to see if the pull request plugin can be improved in that regard. Otherwise, I'm afraid that will be difficult, as the branch for the PR will contain the information and we don't treat those as special branches.
We have the "pull requests" build feature enabled on the build configuration, though it didn't seem to be doing what it was supposed to with Bitbucket Server from what I could tell. So we also set up a separate build config to build the pull requests.
Also, the email we're sending out is triggered by a third, deployment config which depends on the main build config.
If the pull request feature is misbehaving, it would be useful if you could explicitly report about it (I'm not sure if you did, so just in case), as we introduced it recently, and while we consider it to be production ready it makes sense that it might face some specific cases where some behavior is unexpected.
About sending the email, as of now it's not possible, the only option would be if you could create a build configuration that explicitly excludes those kinds of pull requests and set the notification in it. As of now, this feature is not available in notifications, every build that matches the conditions set on the notifications will trigger it.
If you would like to see this feature we can only recommend opening a feature request in the tracker (https://youtrack.jetbrains.com/issues/TW), explaining your use case. We cannot promise that this will be implemented, as it seems a bit of a corner case that would need a lot of work to bring, but if there are enough votes for the scenario it might be worth reconsidering.