In order to demonstrate this ability, we will take the example cited in use case 12, 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.distributed-builds.product1-parallel stands for root.product1@Windows we talked about in this use case.
root.distributed-builds.LinuxBox.component2 simulates the configuration root.component2@Linux.