Filter and Build Failure Messages between Build and Email Notifier
I need some help designing a TeamCity plugin. Here's our situation. We have some projects with many tests. Sometimes a flaky test is introduced into the system. We already maintain some logic that runs as a build step in every project in our build that uses the TeamCity API to tag a particular build as "valid" or "known flaky" based on an external datasource of flaky tests we are already aware of.
I would like to intercept the Build Failed message on the way to the EmailNotifier and drop it if the build does not have a "valid" tag on it. In other words, if we already have a record that the build failed because of a flaky test failing, we don't want to send an email to the committers whose commits triggered the build. Investigating the build failure is not a good use of their time.
At first, I was thinking that I needed to implement a Custom Notifier which wrapped the Email Notifier. But, now I'm thinking that I might be able to use a BuildMessagesTranslator
Is that heading in the right direction. Just looking for a hint. Or, if you've got other ideas on how to accomplish our goal of not notifying the committers when a flaky tests fails, I'd be happy to hear about that as well.
Please sign in to leave a comment.
It turns out that BuildMessagesTranslator is only good for altering the messages that are logged to a the log files during the build.
What I ended up doing was to create a Custom Notificator which delegates to the Email Notificator for all of the notify* methods. Then, on the one method where I wanted to do the filtering, I added the filtering logic. To do, this, you need to use the NotificatorRegistry class to register your Custom Notificator, but it has to be done after the NotificatorRegistry has registered the Email Notificator, or you won't be able to get a reference to it for passing to your own Custom Notificator. So, rather than handling registration when the plugin is installed, I handled registration during the serverStartup() method of the BuildServerAdapter. This method is called after most of the server startup has finished.
Another option would have been to pass the NotificatorRegistry into the Custom Notificator and let it look up the Email Notificator lazily when it is first needed. This allows you to register your Custom Notificator early on.