Take "product2" as example, we create a configuration root.product2 at machine1 to build this product. In this configuration, set up the following things:
Create two repositories:
This repository is created to check out source code of product2 from CVS.
This repository is created to retrieve test log from latest build of configuration root.test-product2@machine2. In this repository, we define a module with source path be "..", and file name pattern be "build_log.txt". In this way, test log will be retrieved (Note that source path is relative to artifacts directory, so we use ".." to change to parent directory of artifacts, which includes the build log file).
Create two builders:
This builder is used to build product2.
This builder is used to publish test log into some sub directory of artifacts directory, so that it can be accessed from web interface.
Create five steps:
This step uses repository1 to check out source code of product2.
This step uses builder1 to build product2.
This step uses repository2 to check out test log of product2. At this point, you may curious about how build result of product2 is sent to machine2. The trick is at root.test-product2@machine2 side. In that configuration, we will define steps to pull latest build result of product2.
This step uses builder2 to publish test log. Step necessary condition property of this step should be set to true in order to publish the test results for review even the step "retrieve test results" fails.
This step executes the above four steps one by one.
Another configuration root.test-product2 needs to be created at machine2 to run test against product2. In this configuration, set up the following:
Set value of property build necessary condition as true, which means new build will always be generated upon triggering. This is needed because this configuration will be dependently triggered by root.product2@machine1, and for each dependent triggering, we want new build of root.test-product2 been generated so that tests can be run.
Create two repositories:
This repository is created to check out build result of product2 from latest build of configuration root.product2@machine1.
This repository is created to retrieve test script from CVS.
Create a builder builder1, which will be used to run test script.
Create four steps as below:
This step uses repository2 to check out test scripts from CVS.
This step uses repository1 to check out build results of product2.
This step uses builder1 to run test.
This step executes the above steps one by one.
In this way, build result of product1 will be tested on machine2, and test results will be collected back to machine1. If test fails (that is, build of root.test-product2@machine2 fails), step "retrieve test results" at root.product2@machine1 side will also fail, which causes build of product2 failed.
![]() | Note |
---|---|
As you may noticed, root.product2@machine1 depends on root.test-product2@machine2 to retrieve test results, and root.test-product2@machine2 depends on root.product2@machine1 to retrieve product2 build results. Obviously there is a dependency loop here. QuickBuild is clever enough to handle this correctly:
|
![]() | Warning |
---|---|
You should never actively trigger a subordinate configuration. Otherwise, deadlock may occur. |
A live demo is available through QuickBuild's demo site http://livedemo.pmease.com:8081/. Within this live demo:
root.distributed-builds.product2 stands for configuration root.product2@machine1 we talked about.
root.distributed-builds.LinuxBox.test-product2 simulates configuration root.test-product2@machine2.