Working with build promotion

For a particular project, I want to set up nightly build, test build, and release build respectively. Nightly builds should not tag the source in any case, while test and release builds should tag the source whenever there is a successful build. Further more, for particular test build that has passed QA tests for example "myproduct-QA-5", I want to promote it as a release build, and assign it with a formal version, for example "myproduct-1.0.5"

  1. Open configuration root.live-samples.usecase3. This is the top level configuration for our sample project. We define necessary repositories, builders, and steps in this configuration.

  2. Under this configuration, we defined three child configurations nightly, test and release, respectively. For test and release configuration, the only thing need to do is setting proper next build version in the basic settings tab. Other objects are inherited from parent, including repositories, builders and steps. For nightly configuration, the label step is not wanted, so we create a new step in the steps tab, and choose overriding 'Label CVS' from the drop down menu of the name property, and choose never run this step as value for the step necessary condition property. In this way the label CVS step created in parent configuration has been overriden, and will never get chance to run. Another way to avoid labeling is to override the default step, and remove the label CVS step from the serial composition.

    [Note]Note

    For release and test builds, it is highly recommended to set them as clean builds. For nightly builds, be set as increment builds will speed up the build process. Generally speaking, clean build is more reliable, and increment build is faster.

  3. Now try to forcibly trigger these three child configurations, you can see all of them should run happily. By examining builds in these three child configurations, you'll find that builds in release and test configuration can be promoted and rebuilt, while builds in nightly configuration can not. The reason is that rebuild and promotion need to repeat the build, which is only possible when labels were created in repository for these builds.

  4. Now suppose that our QA team has thoroughly tested build myproduct-QA-5. We are satisfied with its quality, and want to promote it as a release build. In order to do this, just go to detail page of myproduct-QA-5, click on promote button, the Edit promote settings page will appear. In this page, choose root.live-samples.usecase3.release as the destination configuration, and click on OK. Now myproduct-QA-5 is being promoted in release configuration. The new version will be next build version of release configuration, which we assume as myproduct-1.0.5 here. After the promotion, original test build will be deleted, and the new build will create a new label called myproduct-1_0_5 in CVS.

    [Note]Note

    Under the hood, promotion retrieves sources from repository with label of original build, and go through steps defined in destination configuration to perform the new build. So in order to repeat the original build exactly, source configuration and destination configuration should use the same set of repositories and builders during build.

    [Note]Note

    Another way to perform promotion is just to move a build from one configuration into another, this will not trigger a new build. The limitation is that the version attached original build can not be changed.