Email notifications in build chains

Hi all,

I am wondering if there is a solution for this scenario using build chains:

Build A depends on artifacts from build B, C, and D.
Build B, C, and D have no triggers defined.
Build A has a trigger defined based on changes in VCS detected.

Now, if someone checks in code, the build order of A, B, C, D as it gets queued is:

B
C => A
D

Easy stuff.


Now the problem is if the check-in breaks build B, C, and D. The result is that users get emailed for the break in B, C, and D, and then once more for good measure for build A, having failed its dependencies. The emails look roughly like this:

[TeamCity, FAILED TO START] Build PROJ::A #????--001
[TeamCity, FAILED] Build PROJ::B #1234-001
[TeamCity, FAILED] Build PROJ::C #1234-001
[TeamCity, FAILED] Build PROJ::D #1234-001

(where the build number is #Changeset-BuildID)


What would be a lot better is if we were to only send an email out at the build A level, reporting the entire subset of problems getting there. This way our users would only see a single failure email, and not a lot of noise. I am finding that the signal-to-noise ratio is an indicator of how much the users pay attention to the current build status. The higher the ratio, the less likely it is that people pay attention.

Any solutions out there?

-D

PS: I am running Team City 6.0.1 currently

7 comments
Comment actions Permalink

Hi Derek

We have this issue logged in TW-14162, please vote.
As workaround you can disable The build fails to start notification rule.

Michael

0
Comment actions Permalink

Derek,

Do you refer to notificatinos "builds with my change" or other?

Users can subscribe only to notifications for build configuration A and not subscribe for B, C or D.

Isn't it an option?

0
Comment actions Permalink

This is an option in terms of how the software dictates the workflow.

However, our team does not subscribe to builds individually and this is what makes the issue not solved via option choice. Rather, the way we work is we set up default notification rules per role, and then everyone added to that role 'automatically' is set to be notified when builds with their changes are failing. Ideally, our users will never really have to log into the web UI of the build system ever, the only reason they would need to is if they want to initiate a custom build for some reason (which they can do from within Visual Studio via the brilliant plugin).

0
Comment actions Permalink

Derek,

> Rather, the way we work is we set up default notification rules per  role, and then everyone added to that role 'automatically' is set to be  notified when builds with their changes are failing

I guess you accomplish this with the help of TeamCity user groups. It's still possible to configure notification rules for the group to receive no notifications about build configurations B, C and D, but receive those for A.


> Ideally, our users will never really have to log into the web UI

I understand the approach, but it's really a sad one, as the users miss many TeamCity features this way. Specifically the features designed to save team's time analyzing found problems.

0
Comment actions Permalink

That's a possible scenario that will fix this problem for us, thanks Yegor. Having the notifications determined by group, but only for the resultant builds (A in my scenario) may be a valid option.

And on the subject of 'never having to log into the Team City UI', that's a bit of an over-simplification on my part. Of course our users log in whenever they see and are investigating build breaks - when they want to see the full build log to determine what the problem is. Also, our users will log in from time to time to obtain symbols for various older builds and to send artifacts to people outside our local team. Not sad, just not something anyone other than the build team does on a daily basis!

Another approach that has been suggested to me is to expose 'status-only' builds that could be seen as representative of "A" in my scenario. These builds wouldn't actually do anything, but wait for success of the build chain in its entirety. All of our build projects would have one of these status-only builds, but all the status-only builds would be grouped inside another build definition altogether. The build definition containing all the status-only builds would be exposed to all interested groups/users in team city as being notified in all cases. Everything else (B, C, D builds) would be opt-in only for individuals to select.

I've not attempted the last scenario yet, but will give it a shot soon.

0
Comment actions Permalink

Derek,

Thank you for the details.

The approach with stat-only build configuraiton can work as for me.

0

Please sign in to leave a comment.