Introduction

The personal build client is used to request a personal build on a pulse™ server. A personal build is a build of the latest project source code with the changes in your own working copy. The ability to execute personal builds allows you to test your changes before committing them to your SCM. This helps you to keep the checked in source code passing all tests at all times.

Personal Build Security Before you can request personal builds, you must be granted permission by the administrator of your pulse™ server. For more information, refer to the Groups page in the main pulse™ Manual.

Personal Build Agents Note that agents also have an "allow personal builds" setting that controls whether personal builds may be dispatched to that agent.

How Personal Builds Work

Personal builds are executed by assembling source code changes (usually from your working copy) into a patch file and sending those changes to the pulse™ server. The server will apply the changes to its own checkout of the project source code, then execute a build and notify you of the results as normal. The results of personal builds are available in the pulse™ web interface, much like other builds. Unlike project builds, the results are only visible to the user that requested the build, via their own dashboard. You can also subscribe to notifications for your personal builds, much like you can subscribe to project build results.

The usual personal build workflow is roughly as follows:

• After making some changes, you decide you would like to test them before committing (submitting) them to your SCM.
• You run the personal build client in order to submit a personal build request to your pulse™ server. The client then:
  • Confirms your configuration with the pulse™ server.
  • Prompts you to specify the revision to build against. Usually it is best to choose the latest revision, so you have maximum confidence that your changes will work when committed, but this is not required.
  • Depending on the revision chosen, optionally prompts you to update (sync) your working copy to that revision. This is recommended to detect conflicts early.
  • Analyses your changes, ensuring that the working copy is in a consistent state (i.e. there are no conflicting, damaged or missing files).
  • Collects the changes into a patch file.
  • Requests a personal build from the pulse™ server, uploading the patch file in the process.
  • Outputs the build number corresponding to the request.
• The pulse™ server runs the personal build, notifying you of the results how you choose.
• Based on the results of the build, you may decide to either commit (submit) your changes, or fix any issues that have been identified and repeat the cycle.

The above workflow suits the common case, but also gives you options to handle other cases. For example, you can choose to submit an existing patch file, in one of multiple supported formats. You may choose not to update your local working copy, knowing that the current HEAD revision is broken.

Overview

The remainder of this document is divided into the following sections: