![]() | Warning |
---|---|
In order to make remote build work, you should keep time of different build machines in sync (Normally a slight difference within 5 seconds is tolerable). |
Install QuickBuild on Windows and Linux. Create configuration root.product1 in QuickBuild system running on Windows (refer as root.product1@Windows later), and create configuration root.component2 in QuickBuild system running on Linux (refer as root.component2@Linux later). root.product1@Windows will be used to build component1 and package component1 and component2 into product1, while root.component2@Linux will be used to build component2.
In root.component2@Linux, create appropriate repository, builder and steps so that it can check out source code of component2 from CVS, build component2, and create label on component2 in CVS if build is successful. Artifacts of component2 will be published into some directory of generated build. Do a test on this configuration to make sure it works.
![]() | Note |
---|---|
root.component2@Linux will maintain separate build versions from root.product1@Windows. This is reasonable, cause it's the common case that a product comprises of multiple components of different and independent version numbers. |
In configuration root.product1@Windows:
Create below repositories:
This is a CVS repository which is used to check out source codes of component1 from CVS.
This is a QuickBuild repository which is used to check out build artifacts of component2 from latest build of configuration root.component2@Linux.
Create two builders: builder1 and builder2. builder1 is used to build component1, and builder2 is used to package artifacts of component1 and component2 into product1.
Create below steps:
This step uses repository1 to check out code of component1 from CVS
This step uses builder1 to build component1
This step uses repository2 to check out artifacts from latest build of component2 at Linux box.
![]() | Note |
---|---|
By defining this step, root.product1@Windows is considered to be dependent on root.component2@Linux, and root.component2@Linux will be triggered automatically during the dependency resolving phase, which is happened before retrieving component2 artifacts. |
This step uses builder2 to package artifacts of component1 and component2 into product1
This step does the following things:
Creates a label on source code of component1 in CVS.
Creates a label on root.component2@Linux to mark the build number of component2 whose artifacts are packaged into this version of product1.
This step is a serial composition step that runs the above five steps serially.
In this way, product1 can be built easily. Further more, If product1 contains component3 which should be built on Solaris, you can install another QuickBuild system on a Solaris machine, configure it to be able to build component3, and add corresponding QuickBuild repository to check out artifacts from component3 at Windows side.
A live demo is available through QuickBuild's demo site http://livedemo.pmease.com:8081/. Within this live demo:
root.remote-builds.product1 stands for root.product1@Windows we talked about.
root.remote-builds.LinuxBox.component2 simulates the configuration root.component2@Linux.
In order to demonstrate this ability, we will take the example cited in use case Building multi-platform products, but try to build component1 and component2 simultaneously. Nothing needs to be changed at root.component2@Linux side. At root.product1@Windows side, make the following changes:
Add a repository say repository3. This repository is defined so that it contains source path of both component1 and component2.
Change build necessary condition to be repository["repository3"].modified at basic settings tab of current configuration. The reason for not using effectingRepositoriesModified is that: By using effectingRepositoriesModified, when decides whether or not a new build is necessary, QuickBuild will examine contents of every repository referenced in step definitions to see if they have been modified. During this phase, root.component2@Linux specified in repository2 may be triggered and built (and contents of repository2 are considered to be modified if latest build of component2 happens after latest build of product1), which is not we want. By using repository["repository3"].modified instead, we ignores repository2 during build necessary condition evaluation phase of product1, but still be able to detect changes in both component1 and component2.
Create the following steps:
This step uses repository1 to check out code of component1 from CVS.
This step uses builder1 to build component1.
This step is created to execute the above two steps serially.
This step uses repository2 to check out artifacts from latest build of component2 at Linux box. This step will cause component2 been built if necessary (depends on build necessary condition of root.component2@Linux).
This step is a parallel composition of step "checkout and build component1" and "retrieve component2 artifacts". By using this step, component1 and component2 will be built simultaneously.
This step packages prepared artifacts of component1 and component2 into product1.
This step does the following things:
Creates a label on source code of component1 in CVS.
Creates a label on root.component2@Linux to mark the build number of component2 whose artifacts are packaged into this version of product1.
This step is a serial composition of step "prepare artifacts of component1 and component2", "Package component1 and component2 into product1", and "create label".
A live demo is available through QuickBuild's demo site http://livedemo.pmease.com:8081/. Within this live demo:
root.remote-builds.product1-parallel stands for root.product1@Windows we talked about in this use case.
root.remote-builds.LinuxBox.component2 simulates the configuration root.component2@Linux.
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.remote-builds.product2 stands for configuration root.product2@machine1 we talked about.
root.remote-builds.LinuxBox.test-product2 simulates configuration root.test-product2@machine2.