Team City Conditional Build Execution

I want to create a one-click release build. I am fine creating multiple build configurations and linking them together or building everything in one build configuration.

Module Dependencies are mentioned below:
Module C depends upon module A and B. Module D depends upon module C.

A > C > D
B > C

There could be instances where nothing has been changed on module A or B. If nothing has been changed in a module, I do not want to build and release them as it was already released in past. This would have been simple if I need to build all the modules every time which is not the case.

Let us consider a scenario that there is a change in module B. In this case, I only want to build module B, C & D (but not A).

Is there a way this could be achieved with build step or parameters or by any other means in Team City?


This should be the default behavior of TeamCity if you select the snapshot dependencies to reuse builds if a suitable build is available. Suitable builds do have some conditions that need to be met, so you might want to check them here:


Thanks a lot Denis. This is working fine if builds do not have configuration parameters referred across builds. In my case, module C release build refers to module A and module B release build configuration parameter to fetch the release version of module A and module B. With this configuration, when I trigger module C build, it also triggers and executes module A and module B builds even though there are no changes in module A and module B repositories. Do I need to wait for or there is a workaround for this?


I'm not exactly sure TW-23700 matches your use case. If you are referencing the parameters from A and B on C using "dep.A.parameter", then that should work just fine as far as I can tell. The problem TW-23700 should cover is when you are using A and B with custom parameters, a.k.a. A and B have been run with custom builds setting non-default parameters. If you are exporting the release version as a parameter, that might have that effect, but the problem would be slightly different (although should be covered in TW-23700), and would have an easier workaround, by simply not exporting this as a parameter, but maybe having it as an artifact which then can be read by C.


Would that work for you?


Thanks for your response. Let me provide more information about how builds are set up.

All the build configurations have release version as a configuration parameter.
The release build C refers to dep.A.releaseversion parameter and dep.B.releaseversion parameter, updates the version of module A and B in maven pom properties section and then build module C.
The release build D refers to dep.C.releaseversion parameter, update the version of module C in maven pom properties section and then build module D.

No triggers have been set on build configuration A, B, C & D.
Snapshot dependencies have been added in module C as module A and module B.
Snapshot dependencies have been added in module D as module C.

The snapshot dependencies configuration is as follows:
Do not run new build if there is a suitable one. Only use successful builds from suitable ones.

If there are no pending changes in module A and B and I manually trigger build D, team city is building all modules i.e. A, B, C & D. I do not want to build module A & B in this case as their repositories have no pending changes and they have already been built before.

I am not running custom builds. As per your previous comment, it should work fine as this is not related to TW-23700.
Is the issue related to missing VCS trigger which I do not want in my case? Any pointer would be a great help.


The issue shouldn't be related to a VCS Trigger. The most common issue on this scenario would be that any of the A or B builds have parameters modified on build creation (for example, set through the manual triggering via reverse.dep.parameters).


Do A/B have VCS Roots on them? Are this different from C/D? Are the revisions new in "D" when you trigger it available for A/B, just ignored on some setting?


Thanks a lot for your Denis. The issue was related to a parameter (shared across build as dep.parameters) getting modified which was triggering complete build chain. The issue has been resolved now.


Please sign in to leave a comment.