Set Up Build Dependency

Version 9 by Robin Shen
on Aug 10, 2009 02:38.


compared with
Version 10 by Robin Shen
on Aug 10, 2009 03:16.


Key
These lines were removed. This word was removed.
These lines were added. This word was added.

View page history


There are 4 changes. View first change.

 It is quite common that a product is comprised of different components, and a component is used by different products. We suggest to set up builds for these components and products separately in this case, and utilize QuickBuild's dependency mechanism to use result of component builds in product builds.
  
 h1. Dependency mechanism
  
 QuickBuild implements build dependency through a special repository type - [QuickBuild repository]. Assume we have two configurations: _root/product_ and _root/component_. Configuration _root/product_ is created to build the product, and configuration _root/component_ is created to build component. To use component artifacts, you will need to:
 # Switch to _repositories_ tab of _root/product_, and define a QuickBuild repository there retrieving desired files from desired build of _root/component_.
 # Switch to _steps_ tab of _root/product_, and add a checkout step into step execution graph to check out from the repository defined above.
  
 If the product depends on multiple components, you will just need to define multiple QuickBuild repositories corresponding to these components, and add multiple checkout steps to check out from these repositories in the product configuration.
  If the product depends on multiple components, you will just need to define multiple QuickBuild repositories corresponding to these components, and add multiple checkout steps to check out from these repositories in the product configuration. You can even arrange these checkout steps in a parallel composition step to resolve and retrieve multiple dependencies simultaneously.
  
h1. Dependency resolution
  h1. Dependency resolution and change detection
  
 Taking the example used in the above section, before retrieving artifacts from configuration _root/component_, QuickBuild needs to determine which build in _root/componentA_ to be used. The process of resolving dependency build is called dependency resolution in QuickBuild, and is controlled by the property _build_ when define the QuickBuild repository as shown below:
 !dependency.png!
Embedded help of this property explains meaning of different choices and how they affect the dependency resolution process.
  Currently this property can take one of below value:
 * latest finished build (generate new if necessary)
 If this value is selected, QuickBuild will check if a new build is necessary in the dependency configuration (_root/component_ in this case) when resolve the dependency build. If the build is necessary, the newly generated build will be used as the actual dependency build; otherwise, the current latest finished build will be resolved.
 You can also specify variables to customize the dependency build process in this case.
 * latest finished build
 If this value is selected, QuickBuild will directly resolve the dependency build as the latest finished build without attempting to generate a new build in the dependency configuration even if build condition is satisfied.
 * latest recommended build
 If this value is selected, QuickBuild will resolve the dependency build as the latest recommended build. This is very useful to make sure that the product builds always use good and approved builds from component configurations. Newly introduced features in component builds will not affect product builds unless they are approved.
 * latest successful build
 If this value is selected, QuickBuild will resolve the dependency build as latest successful build.
 * specify a build version
 This choice introduces a static dependency. The dependency build version is manually specified and will not be changed unless you set it to another version.
  
 h1. Change detection
  
 Just as other repository types, changes will be detected from QuickBuild repository if [dependent build] is triggered.
  The dependency resolution process is recursive if the dependency configuration itself uses other dependencies. Other dependency resolution processes will be triggered before current resolution finishes.