It is a new feature request, not a defect. But I agree it would be useful.I have no time to implement this feature in short-term, but I will be happy to review the pull-request if you have time to work on it. It should be pretty trivial to implement.

Right now you can use Ownership Token Macros to set recipients in classic project types and "ownership" global variable in Jenkins Pipeline. Output of OWNERSHIP Token Macro output format has been specifically developed for Mail Ext.

oleg_nenashev, while trying to find a way to add email addresses from ownership plugin to a generic notifybuild utility function I discovered that the plugin can raise an exception if I ask for node owners when I am outside the node block.

While I do understand the why you had to do this, I am wondering if there is way to avoid this error. I have no control where the user of the notifyBuild() is adding its code, if is inside or outside node {}, so I want to make it safe to be used in any location.

See code at https://github.com/pycontribs/powertape/blob/master/vars/notifyBuild.groovy#L44

Any hints on how to do that? Throwing an exception is much worse than missing to add some emails to the notification, probably the best would be if I would only raise an warning.

Also there is another aspect: usually you want to send only one email notification per build and to send it on any kind of failure. This means that you need to add the email part on the the topmost finally {} block, one that is not inside any node.

I guess that only solution that would make everyone happy would be if the ownership plugin can "collect" the owners of used nodes during execution and keep them available in a global variable. I don't even know if there is a hook that could allow this kind of collection.

Unassigned so anybody can pick the issue.

> while trying to find a way to add email addresses from ownership plugin to a generic notifybuild utility function I discovered that the plugin can raise an exception if I ask for node owners when I am outside the node block.

Throwing exception is definitely correct in the current implementation. I prefer operations to fail fast. OTOH we could add a flag, which alters the behavior if an admin really wants that.

Same for the node collection, it is an extra functionality (which could be useful).

Please create separate tickets for both cases. If you are ready to contribute pull requests, I will be happy to review them.