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:
C => A
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?
PS: I am running Team City 6.0.1 currently