I am running TeamCity 2018.1. I can't seem to find the answer to this scenario anywhere. I have found similar questions, but they don't address exactly what I'm trying to achieve: here and here
I want the following flow in TeamCity
1 -> 2.1 -> 3
1 -> 2.2 -> 3
1 -> 2.3 -> 3
2.4 -> 3
2.x deploys different services to a test environment, and 3 runs smoke tests against the test environment, so we don't need multiple of those run. If 1 is triggered, that is exactly what happens if using Finish Build Triggers. It ends up cluttering our feeds, and we end up with test runs that have a service deployed in the middle of the run, which we absolutely need to avoid.
Requirements are as follows:
- I want 3 triggered any time a 2.x finishes, BUT I do not want multiple builds of 3 run, like in the case 1 is triggered first.
- I also want 3 to be triggered when there is a checkin on its default branch.
- Triggers on 3 should not build anything earlier in the build chain. This is an expensive operation, and will confuse our results in our smoke tests (did a failure happen because the tests changed? or because we deployed updated code?)
I was led to believe that snapshot dependencies would fix this problem, but it's not working how I want it to. It doesn't seem to be triggering 3 when any 2.x finishes successfully. Also, I absolutely do not want 1 or 2.x triggered when 3 is triggered by a VCS change, which seems to happen a lot regardless of the "use a suitable build option."
Also, 1, 2.x, and 3 all run from different repositories, so they have no VCS roots in common. All the 2.x builds are different repos as well. We have no artifacts to pass along either.
How can I achieve this workflow?
Edit: Is this possible by adding a dummy build configuration before my test runs?
