Overview
The checkout scheme defines two things:
- Whether a clean working copy is used for each build
- How the project source code is obtained from the SCM.
Details of the available schemes, along with their advantages and disadvantages are described below.
Schemes
The three checkout schemes currently available are:
Clean Checkout
The "Clean Checkout" scheme, will always check out a fresh copy of the source from the SCM and rebuild from scratch. This is the default behaviour, and has the advantage of guaranteeing that the build is executed in a freshly checked out directory. This scheme is recommended for those projects where checking out the full source and rebuilding does not introduce too much of a delay into the build cycle.
Clean Update
The "Clean Update" scheme makes use of a local check out directory to improve the efficiency of updating the source code. When a specification is built for the first time, the source files are checked out into a directory on the server, and copied into the build directory. Each build after that will trigger an update of the source files followed by a copy into a clean build directory. The advantage of this approach is that pulse™ will only retrieve the latest changes from the SCM. This scheme may be used as an optimisation for projects where checking out the source takes a significant amount of time. Clean rebuilds are maintained by copying into a clean build directory every time.
Incremental Update
The "Incremental Update" scheme keeps a working copy of the project source code and reuses it for multiple builds of the same build specification. When the specification is built for the first time, the source files are checked out directly into the build directory. Each build after that the source code will be updated and the build executed in the same directory. The advantage of this approach is that it allows incremental builds. The disadvantage is that builds are not isolated from one another: the artifacts from one build can affect the next. This scheme is recommended for projects that have build cycles too long to allow clean rebuilds.
Forcing Clean Checkouts
When using either the "Clean Update" or "Incremental Update" checkout schemes, it may be necessary at times to force a clean checkout and rebuild. For example, a bug in build dependency management may cause incremental builds to fail. In this case you can force a clean checkout and rebuild by editing the build specification. From the project "configuration" tab, click the "edit" link for the appropriate build specification. In the top right hand corner of the build specification page, click the "mark for clean build" link. This will ensure that the next build of the specification will begin with a clean checkout.
In some situations, pulse™ itself may force a clean checkout and rebuild. For example, when you edit the SCM details for the project, pulse™ will ensure that the changes take effect by forcing clean rebuilds.
Examples
It is not uncommon for the SCM to host third party dependencies required to build a project. When this is done, checking out that project can take a significant amount of time (each time the checkout is run, all of the third party dependencies are checked out). This is waste of both time and bandwidth. In such cases, the "Clean Update" scheme is recommended.
