{anchor:configuration} *Configuration*
Configuration holds all configuration information needed to generate builds. This information includes what to build, how to build it, and when to build it, etc. Configurations are organized in a tree structure. To refer to a configuration, name of all its ancestor configurations should be chained together and connected with forward slash, for example: _root/department1/project1/nightly_. This is called configuration path. Further, to refer to a configuration at particular QuickBuild server, we use the format _<configuration path>@<build server>_. For example: _root.department1.project1.nightly@buildserver1_. Child configurations can inherit build settings from its parent, and they can selectively override some of the settings. This behavior is referred as inherit and override rule, which makes build management of many projects quite easy.
{anchor:build} *Build*
Build is generated by running a configuration. When the particular configuration is requested to run (either by user or by scheduling system), the _build necessary condition_ of the configuration will be evaluated. If the result of the evaluation is _true_, a new build will be generated.
{anchor:configuration directory} *Configuration Directory*
Every configuration has an associated configuration directory which is named by the configuration identifier, and resides under the _configurations_ directory. This directory holds configuration log, various statistics information about the configuration, and the configuration workspace.
{anchor:configuration workspace} *Configuration Workspace*
Every configuration has an associated workspace directory which is named by _workspace_ and resides under the configuration directory. The workspace is the place where the build for the associated configuration actually happens, for example, source code will be checked out to this directory (or its sub directory based on configuration repository setting), and build script will be called from this directory (or its sub directory based on configuration build setting) to generate build artifacts, etc.
{anchor:build directory} *Build Directory*
Every build has an associated build directory which is named by the build identifier, and resides under the _builds_ directory. This directory holds build log, build artifacts, and various build reports.
{anchor:build agent} *Build Agent*
{anchor:build artifact} *Build Artifact*
{anchor:build dashboard} *Build Dashboard*
{anchor:build notification} *Build Notification*
{anchor:build report} *Build Report*
{anchor:build state} *Build State*
{anchor:build statistics} *Build Statistics*
{anchor:build version} *Build Version*
{anchor:code coverage} *Code Coverage*
{anchor:code duplicate} *Code Duplicates*
{anchor:code inspection} *Code Inspection*
{anchor:configuration} *Configuration*
{anchor:configuration dashboard} *Configuration Dashboard*
{anchor:build grid} *Grid*
{anchor:notification strategy} *Notification Strategy*
{anchor:quickbuild plugin} *QuickBuild Plugin*
{anchor:step} *Step*
{anchor:vcs} *Versioning Control System*
{anchor:workspace} *Workspace*
Configuration holds all configuration information needed to generate builds. This information includes what to build, how to build it, and when to build it, etc. Configurations are organized in a tree structure. To refer to a configuration, name of all its ancestor configurations should be chained together and connected with forward slash, for example: _root/department1/project1/nightly_. This is called configuration path. Further, to refer to a configuration at particular QuickBuild server, we use the format _<configuration path>@<build server>_. For example: _root.department1.project1.nightly@buildserver1_. Child configurations can inherit build settings from its parent, and they can selectively override some of the settings. This behavior is referred as inherit and override rule, which makes build management of many projects quite easy.
{anchor:build} *Build*
Build is generated by running a configuration. When the particular configuration is requested to run (either by user or by scheduling system), the _build necessary condition_ of the configuration will be evaluated. If the result of the evaluation is _true_, a new build will be generated.
{anchor:configuration directory} *Configuration Directory*
Every configuration has an associated configuration directory which is named by the configuration identifier, and resides under the _configurations_ directory. This directory holds configuration log, various statistics information about the configuration, and the configuration workspace.
{anchor:configuration workspace} *Configuration Workspace*
Every configuration has an associated workspace directory which is named by _workspace_ and resides under the configuration directory. The workspace is the place where the build for the associated configuration actually happens, for example, source code will be checked out to this directory (or its sub directory based on configuration repository setting), and build script will be called from this directory (or its sub directory based on configuration build setting) to generate build artifacts, etc.
{anchor:build directory} *Build Directory*
Every build has an associated build directory which is named by the build identifier, and resides under the _builds_ directory. This directory holds build log, build artifacts, and various build reports.
{anchor:build agent} *Build Agent*
{anchor:build artifact} *Build Artifact*
{anchor:build dashboard} *Build Dashboard*
{anchor:build notification} *Build Notification*
{anchor:build report} *Build Report*
{anchor:build state} *Build State*
{anchor:build statistics} *Build Statistics*
{anchor:build version} *Build Version*
{anchor:code coverage} *Code Coverage*
{anchor:code duplicate} *Code Duplicates*
{anchor:code inspection} *Code Inspection*
{anchor:configuration} *Configuration*
{anchor:configuration dashboard} *Configuration Dashboard*
{anchor:build grid} *Grid*
{anchor:notification strategy} *Notification Strategy*
{anchor:quickbuild plugin} *QuickBuild Plugin*
{anchor:step} *Step*
{anchor:vcs} *Versioning Control System*
{anchor:workspace} *Workspace*