How can I trace down exactly why TeamCity chooses to build a dependent project?
I have release projects for SIT, UAT and PROD. Since I want my build number for each to come from the continuous build it was associated with, I have a chain of snapshot dependencies:
Release.SIT depends on Continuous
Release.UAT depends on Release.SIT
Release.PROD depends on Release.UAT
Then the appropriate build numbers are set using the %dep.btX.build.number% property. So we can see at a glance that build #140 has been deployed to SIT & UAT but not PROD etc.
This all works... BUT I am finding circumstances where running one of those projects will trigger a build of the predecessor when there is no obvious reason that it should (the predecessor has been manually run just prior). I have a suspicion of the cause but I can't find any documentation or know what logs to look at if any to find out why for sure.
The Release.SIT and Release.UAT projects are actually configured with some build parameters which are UI interactive. They allow us to reuse the same single TC project but release to one or more environments at that level. So we have SIT1, SIT2, UAT1 and UAT2 environment, and thanks to TC7 we have an interactive prompt that pops up at the time you run the build and asks you where you want to deploy to. This works really well, great feature.
However my suspicion is that TeamCity's logic to decide whether it needs to trigger a predecessor build is based around taking build parameters into account somehow? Such as requiring the predecessor to have been run with it's default build parameter values???
For instance I have a build parameter setup called system.Deploy.UAT.Environment which I use as my deployment destination. In the Release.UAT template/build project this variable is setup to have values of UAT1 or UAT2 with an interactive dropdown. My MSBuild script then utilises the value of that variable. However my Release.PROD template/build project *also* has a build parameter setup called system.Deploy.UAT.Environment variable which indicates the environment I want to deploy from, again for the MSBuild script to deal with. Each of those parameters has to have a default value of UAT1 or UAT2 set in the project (since blank isn't a value for the dropdown). Currently my default is set to UAT1 on each. However I found that if I ran Release.UAT with a value of UAT2, and then Release.PROD with a value of UAT2, that Release.PROD would then trigger a run of Release.UAT with a value of UAT1 !
Hence it is almost as if the logic in TeamCity is looking to see whether the predecessor build has been run with its *default* build parameter values - does that make sense? Or is it something to do with some conflict of build parameter values since I use the same names?
Would greatly appreciate any insight. I have found that if I run SIT1 -> UAT1 -> PROD then everything behaves as I would expect and the dependent build is not re-run. However combinations outside of that are causing major problems.