You are viewing an old version (v. 18) of this page.
The latest version is v. 24, last edited on Aug 09, 2009
(view differences
|
)
<< View previous version | view page history | view next version >>
<< View previous version | view page history | view next version >>
Introduction
Repositories need to be defined in order to set up configuration to build against source code in SCM. Before going further, let's define following concepts:
- repository snapshot
Repository snapshot represents a fixed set of source code in the repository, that is not affected by new checkins - repository revision
Repository revision is used by QuickBuild to identify repository snapshot. It has different meaning for different SCM:- for Subversion: it is the revision number of the repository
- for Perforce: it is the changelist number of the repository
- for Accurev: it is transaction number of the repository
- for other repositories: it is timestamp of the repository
After a repository is defined, you can use it as described in following steps:
- checkout step
This step let you choose a repository to checkout. This is the only way to checkout files from SCM in QuickBuild. When this step runs, QuickBuild automatically takes a snapshot of the repository so that later steps (for example, the label step) operate on the same set of source code used for checkout. - label step
This step let you choose a repository to create label on. This step is useful if you want to label the SCM for the set of source code used for the build. This step will also take a snapshot of the repository. - take snapshot step
This step allows you to choose a repository and to take a snapshot against that repository. The revision number of the repository object defined in QuickBuild will be set to a fixed value after a snapshot is taken.
Examples
With these steps, you can design very flexible workflow when interacting with SCM. You can even define multiple repositories, and checkout/label all of them in a single build.
Here are some examples:
- Define your repository.
- Define a checkout step to checkout from your repository.
- Define necessary steps to build and test your code.
- Define a label step to label the repository that is used for checkout.
- Define the master step as a sequential step to include steps defined above.
- Define your repository.
- Define a label step to label the repository.
- Define a checkout step to checkout from the labeled repository.
- Define necessary steps to build and test your code.
- Define the master step as a sequential step to include steps defined above.
Checkout different part of the project from different machines in parallel, but use the same repository revision
Let's assume that in your SCM, the project is represented by project1, and it has two modules project1/componentA and project1/componentB
- Define a repository representing project1.
- Define two repositories representing project1/componentA and project1/componentB respectively. Revision of both repositories should be set as:
${repositories.get("project1").revision}
- Add a step to take snapshot of repository project1.
- Add two steps to checkout from repository componentA and componentB. You may arrange these two steps running on different machines using node match condition (refer to [build grid] documentation).
- Add a parallel composition step to run the checkout steps in parallel.
- Define the master step as a sequential step to include the take snapshot step and the parallel composition step defined above.