Preventing Unnecessary Triggers On Teamcity

Question

I searched my problem on both questions and answers. I could find a question same as my problem but, what a pity, it's not answered.

Prevent Excessive Builds in TeamCity

I have lots of modules and same situation for lots of dependencies.

To simplify;

I have X, Y, Z modules and dependencies like that: Z->Y->X

When a code commited to X module, X1 started to run.

When X1 completed, Y module triggered and Y1 started to run.

When Y1 completed, Z module triggered and Z1 started to run.

While Z1 runs, a code commited to Y and Y2 started to run.

At this point, since Z2 will be triggered as soon as Y2 completed, Z1 build will become needless. Because Z2 is newer and Z2 must be used.

On the other hand, the modules depends on Z will be triggered unnecessarily (when Z1 finished) too, since Z2 gonna trigger same modules when Z2 finished.

I checked Teamcity documentation; also forums. I don't think it is rare situation but cannot find an answer or solution.

Any help will be appreciated.

Answer 1

I understand the pain but I think the way this works is necessary to properly map problem builds to the code changes that prompted them. For example if Z1 finishes successfully and has 5 changes in it, but Z2 fails and has 3 more changes in it you would not necessarily want the code from Z1 to be associated with a failed build.

if the builds are taking a long enough time or costing compute resources you would rather not spend you could look into cancelling the Z1 build, I don't know of a built in mechanism for this but you could write your own plugin or possibly script it via a build step

the rest API in team city provides some ways to handle this, you can see more here

Answer 2

1. If you setup dependencies in teamcity ,there is a setting for silent period. For ex if you check in something and have a silent period of 5 min, teamcity will wait for 5 mins before it kicks off the build . You can use the slient period option if your commits happen in short bursts. however, if commits across your team are frequent , this is not going to solve your problem.

2. You can also use the "Suitable build" option in your dependencies if commits in your project are frequent. I would suggest you read it up at https://confluence.jetbrains.com/display/TCD8/Snapshot+Dependencies to get a better idea and see if it is suitable to your requirements.

3. Are your builds fast, in that case i actually won't mind seeing X1-Y1-Z1 finish before running X2->Y2->Z2. the reason is that it is easier to identify whether a commit in Z1 broke the build or a commit in Z2 if you run snapshot dependencies. If you run Z1 and Z2 as part of the same build,it becomes a bit more difficult and time consuming t figure out which individual commit started causing build issues

EDIT

We normally have this issue with X1->Z1 . In our case X1 runs super fast while Z1 takes a lot of time. What teamcity does in this case is if there is an X2, it just does not run Z1. It straight away starts with Z2. We achieve it using snapshot dependencies and build chains.

2 questions for you

1. Are all your builds super fast or do they take time.
2. Are all your builds from different repos/sub-repos or do they run of the exact same repo.

A simple hack that you can do is give all builds a version number in build X , write it to a file or teamcity property and propagate them through X1-Y1-Z1 (you can propagate them using parameters from dependent builds). For each build in Y and Z, you can check if X has moved to a higher version.

For x consider this scenario, 1. if your X1 build is v1.1 and your Y1 completes and now Z1 starts to run. 2. Meanwhile X2 has finished running and the new version is 1.2 3. In the target Z2, you can check that the new version is 1.2 and since you are running on v1.1 , you skip the run alotgether( I will let you decide if you want to skip or error out based on your requirements)

If you have the option of building X1 on each commit, you can even do this in Y1 target