Dependent build trigger vs. dependency

I'm a little confused about the difference between a build trigger that's dependent on one configuration and a dependency on sources.

I have a configuration called Unit Tests which does a checkout and compile then runs the unit tests. I have another configuration called Database Tests which doesn't check out any code from vcs and has the checkout directory set to the same one as the unit test configuration. It runs a different set of tests via a nant target.

The database tests configuration triggers off of a successful build of the unit test one. Is this a good practice or should I change this to create a source dependency between the two?

I'm not sure what the best option is here?

Thanks.

3 comments
Comment actions Permalink

Bil,

Sorry for the delay in reply.

I'll sum up some points of Dependency trigger vs. Dependency by sources (we tend to call it "chain" dependency).

Chain dependency:
- ensures that before each build of A starts, build of B is ready for the same sources slice as A
- both A's and B's builds freeze their revisions while still in the queue and are triggered with fixed revisions.
- when A depends on B with artifact dependency, A can take the artifacts from the build of B belonging to the same build chain

Dependency trigger:
- each build takes the latest repository sources on the moment of the build's start
- builds do not have any other relation between each other except for the A is put into the queue after B's finish.


So, chain dependency is more suitable for building several components of the same big system or breaking one single build into parts.
Dependency trigger is more suitable when establishing relations between components of different systems.

I have a configuration called Unit Tests which does a checkout and compile then runs the unit tests.
I have another configuration called Database Tests which doesn't check out any code from vcs and has the checkout directory set to the same one as the unit test configuration.
It runs a different set of tests via a nant target.


I'd recommend you to configure Database Tests to do a checkout by itself and if necessary, artifact-depend on the unit tests configuration to get the binaries to test. In this setup you should probably use chain dependency as both builds should use the same sources.

The advantage of this setup would be that you get the changes in the Database Tests and can easily track what changes caused a build failure, if any. This approach will also work if you setup several agents that can be used by both configurations.

I also should note that currently, when there are multiple compatible agents, there are no means to ensure dependent builds go to the same agent (we will address this in the further releases).

--
Best regards,

Yegor Yarko
Project Manager (TeamCity)
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

0
Comment actions Permalink

Hi Yegor,

I have a pretty similar setup but instead of two builds there are a bunch more dependent builds. So build "Master" is the main one that builds binaries and from that I kick of builds "Test 1", "Test 2", "Test 3", etc. They all share the same VCS root and the test builds need source to be in sync with the "master" build.

I had it set up like so:

Master - triggered by vcs, produces artifacts
Test 1 - triggered by master (Build Triggering -> Dependencies tab), also has source dependency on master and artifact dependency on master
Test 2 - same as Test 1
Test 3 - same as Test 1

When I did this I ended up seeing Master builds in the queue triggered by each of the Test builds. So one original Master build would end up with a queue of 6 subsequent builds instead of 3. Example:

Master - triggered by Test 1
Test 1 - triggered by Master
Master - triggered by Test 2
Test 2 - triggered by Master
Master - triggered by Test 3
Test 3 - triggered by Master

I'm not sure if this happened because I have 3 dependent builds, because I have 3 agents or because it is misconfigured somehow. Does the setup sound correct? Any guess why I'd get so many instances of Master interjected?

Thanks,
Tom

0
Comment actions Permalink

Tom,

If I understood your set right, only one Master should be run out of the three placed in the queue. And all the Test configurations should depend on the single Master build. Is it the case?

Do you need to have the dependency trigger from Master to Test configurations? You probably need this only if you need to run Test after a change that went to Master only.
If a change occurs in Test configuration only, that can result in 3 configurations to be built: Test (triggered by VCS trigger), Master (triggered by Test within chain/sources dependency) and Test (triggered by Master with dependency trigger). We just added a fix to prevent Test from extra triggering (via dependency trigger) in this case. The fix will be available in the next EAP release.

A kind of workaround:
If you need to run all the Tests plus Master on a change in any, you can try to setup "All" configuration that will chain/sources-depend on all the three Test configurations and has VCS roots configured to have all the changes of Tests and Master.

--Yegor

0

Please sign in to leave a comment.