| | 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.| |