Using VCS triggers is launching more builds for a given change than launching them by hand:
I'm using TeamCity 6.0.4 with Perforce, and trying to set up VCS triggers.
My project setup:
Project A produces a shared library.
Project B produces an app, linked to the shared library from Project A.
My end goal: to set up automatic builds such that:
1) Any source change to Project A only triggers a build of Project A.
2) Any source change to Project B only triggers a build of Project B.
3) Any change to the API headers triggers a build of Project A *and* Project B.
Let me re-iterate that I need to ensure that the headers used in Project B must have also been used to build the library it gets from Project A.
My attempts thus far:
Project B has an artifact dependency on Project A's library.
Project B also has a snapshot dependency on Project A, to ensure that its headers are consistent with those used to build Project A.
Project B has two VCS roots: VCS_b containing the bulk of its source and headers, and VCS_shared containing the shared API headers
Project A has two VCS roots: VCS_a containing everything it needs (including shared API headers**), and it then shares VCS_shared.
When triggering builds manually, this works as expected. That is, a source code change to Project A only affects Project A, whereas a change to one of the common header files in VCS_shared will cause both Project A and Project B to need to be rebuilt, and Project B will correctly wait for Project A to be built.
However, when I try to set up a VCS trigger, and change one of the common headers -- Project A gets built twice: once as its own build, and once as part of a build chain started by Project B. In fact, both builds of Project A seem to have the correct (new) versions of the header file.
Does anyone know why TeamCity doesn't seem to realize that these builds are identical? Manually, it seems this situation gets sorted out in the build queue -- I can't figure out what's different about VCS-trigger-initiated builds.