Best trigger/dependency setup for large project dependency tree

Hi,

We've got roughly 20 projects with lots of dependencies between them. I've tried loads of different trigger and dependency configurations but have never been able to get TeamCity 6.5.4 to quite work how I'd like it.

Given the following example setup:

Project Dependencies
A None
B A
C B
D B
E None
F C, D and E
G F
H F
I H


Then I'd like the following behaviour:

  • If a project changes; all dependent projects in the entire tree will get built in the same build chain. So, for example, if E changes, projects E, F, G, H and I get built.
  • If a leaf project changes (in this example projects G or I), then dependent builds only get built if they have changed within the same build chain. So if only G has changed, I shouldn't need to go and build everything else as it hasn't changed.


I also want to setup a seperate build configuration for automated deployment that can access all the artifacts of all projects from the last build chain.

Is there a standard/preferred way of doing this? I have the following setup, however dependent projects never get built:

  • Shared VCS root for all projects
  • VCS checkout rules only specifies a checkout for the project (project B's configuration only specifies the location of B in VCS)
  • VCS trigger only on the location of the project (project B's configuration only specifies the location of B in VCS)
  • 'Trigger on changes in snapshot dependencies' ticked for all projects
  • Snapshot dependency on all dependent projects (project F has a snapshot dependency on A, B, C, D, and E)
  • Artifact dependency (from the same chain) on all dependent projects.


I also just tried adding the location of all dependent projects to the VCS trigger rather than rely on the 'Trigger on changes in snapshot dependencies', but that didn't seem to work either. Is it because I only specify the current project in the checkout rules?

Many thanks
James

3 comments
Comment actions Permalink

Hello James,

Could you please describe in more details what is not working in your case? The VCS trigger does not trigger dependent build when change is detected in its dependency? Or something else?

0
Comment actions Permalink

Hi Pavel, thanks for your reply. I was actually just about to post an update as I figured out what the problem was.

Basically, because the VCS trigger states a trigger rule to only trigger on a change to that project, this filtered out any other type of triggering from changes to other projects, regardless on whether the 'Trigger on changes to snapshot dependencies' was ticked or now. There's two ways to actually fix this:

  1. Add to the VCS trigger rule all the VCS locations of your snapshot dependencies
  2. Don't have a VCS trigger rule at all! Even though this is counter-intuitive (as you'd think that your build would get triggered all the time) TeamCity does in fact add the build to the queue but then works out that there's no change and then removes it. So you get the behaviour that you want.


So I've now got the setup that I was after in my original post above.

Thanks
James

0
Comment actions Permalink

Answered in my final post.

0

Please sign in to leave a comment.