QuickBuild Documentation
|
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. Dependency mechanismQuickBuild 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:
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. Dependency resolution and change detectionTaking 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:
The dependency resolution process is recursive if the dependency configuration itself uses other dependencies. In this case, other dependency resolution processes will be triggered before current resolution finishes. Like other repository types, changes will be detected in the QuickBuild repository when configuration root/product is triggered. When detecting changes, the dependency resolution process will run to get the actual dependency build. If the resulted dependency build is different from the dependency build used in previous build, QuickBuild will think that the dependency has changed and new build will be generated if the configuration is triggered by scheduler or by a recursive dependency resolution process. Dependency typesDifferent dependency types are defined based on different resolution processes introduced above:
Having explained dependency types, let is assume that configuration project1 actively depends on project2, and project2 actively depends on project3. If project3 has new source commits since last build, triggering of project1 will generate new build in project3, project2 and project1 in turn. Check dependent buildsIn a continuous integration environment, when build/test a configuration, it is sometimes desirable to check if configurations depending on current build are successful or not. If dependent builds are failed, the dependency build will be marked as failed to indicate that it breaks the dependents. To achieve this, you will need to:
Future versions will add a dependent trigger step to find out configurations actively depending on current configuration automatically, and trigger them parallely. Track build dependenciesUsed dependencies in a particular build can be examined from the build overview page as explained here. |