Dashboard > Pulse v2.0 > ... > Developer Tools Manual > Personal Build Client > Information > Page Comparison
  Pulse v2.0 Log In | Sign Up   View a printable version of the current page.  
  Personal Build Client
Version 1 by Jason Sankey
on Nov 12, 2008 23:51.


 
compared with
Current by Jason Sankey
on Nov 20, 2008 18:42.

(show comment)
 
Key
These lines were removed. This word was removed.
These lines were added. This word was added.

View page history


There are 1 changes. View first change.

 h2. Introduction
  
 The {firstuse}personal build client{firstuse} is used to request a [personal build|Personal Builds] on a {pn} 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|SCMs]. This helps you to keep the checked in source code passing all tests at all times.
  
 {note:title=Personal Build Security}
 Before you can request personal builds, you must be granted permission by the administrator of your {pn} server. For more information, refer to the [Groups] page in the main {pn} [Manual].
 {note}
  
  {note:title=Personal Build Agents}
 Note that agents also have an "allow personal builds" setting that controls whether personal builds may be dispatched to that agent.
 {note}
  
 h2. How Personal Builds Work
  
 Personal builds are executed by taking a snapshot of your current source code changes (from your working copy) and sending those changes to the {pn} 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. To efficiently and effectively check your changes against the latest project source code, the personal build client updates (or _syncs_ in Perforce terminology) your working copy before taking the snapshot. The 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|SCMs].
  * You run the personal build client in order to submit a personal build request to your {pn} server. The client then:
  ** Confirms your configuration with the {pn} server.
  ** Automatically updates (syncs) your working copy to reflect the latest code in the repository.
  ** 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 {pn} server, uploading the patch file in the process.
  ** Outputs the build number corresponding to the request.
  * The {pn} 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 results of personal builds are available in the {pn} 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|Dashboard Section]. You can also [subscribe|User Subscriptions] to notifications for your personal builds, much like you can subscribe to project build results.
  
 h2. Overview
  
 The remainder of this document is divided into the following sections:
  
 ||Section||Description||
 |[Configuring the Personal Build Client]|Describes how to configure the client to request personal builds.|
 |[Requesting Personal Builds]|Describes how to invoke the client to request a personal build.|
Zutubi wiki is Powered by Atlassian Confluence, the Enterprise Wiki. (Version: 2.2.10 Build:#528 Nov 29, 2006) - Bug/feature request - Contact Administrators