Overview

Before requesting personal builds, you must configure the client. Required configuration includes the URL and credentials used to contact the pulse™ server, the details of which project to execute, and potentially some SCM-specific configuration.

Configuration

Automatic Configuration

If the personal build client is detects that some required configuration is missing, it will attempt to fill in the necessary information by prompting for input. This is the simplest way to configure a new work environment. The configuration gathered is stored in two places:

• Your home directory: configuration likely to be shared among multiple projects (e.g. the address of the pulse™ server) will be stored in a properties file in your home directory.
• The current working directory: configuration specific to one project will be stored in a properties file in the directory where the personal build client was invoked.

For best results, invoke the client from the base directory of your working copy. For more information regarding the properties files created, see below.

Configuration Files

The primary way to provide configuration details is via properties files. The personal build client searched for properties files named ".pulse2.properties", and applies the configuration found within them. Properties files are searched for in the following way:

• The client checks for a ".pulse2.properties" file in its own working directory (i.e. the directory from where the client was executed).
• The client then checks the parent of the working directory, and then its parent, and so on to the root of the filesystem.
• Finally, the client will check in the user's home directory.

All properties files found will be used to form the configuration details. If a property is present in two or more files, the file found earliest in the search will take precedence over those found later. You can also provide and/or override properties using command-line arguments, see Requesting Personal Builds for details.

This system of properties files allows you to store configuration shared between multiple projects in one file, and then use a properties file in each of your working copies for configuration specific to a project. For example, say you work on two projects "p1" and "p2". You check these projects out into directories under a single "work" directory:

work/
  p1/
  p2/

These projects are both built using the same pulse™ server. To configure the personal build client for both projects, you can use three properties files:

work/
  .pulse2.properties: contains the pulse URL and your pulse user name and password
  p1/
    .pulse2.properties: contains the name of the pulse project p1
  p2/
    .pulse2.properties: contains the name of the pulse project p2

This layout allows common configuration to be shared instead of duplicated for each project.

Configuration File Format

The properties files use the standard Java format. This is a simple format for specifying key-value pairs. Each pair is specified on its own line, with the key and value separated by an equals sign ('='). For example, to set the property 'myproperty' to the value 'example value', you would use the following line:

myproperty=example value

Configuration Properties

Core Properties

The core properties are all required to execute a personal build.

Workflow Properties

These are properties that control the personal build client workflow. Often these properties are specified using menu selections or command-line options, but you may choose to make these changes permanent using these properties.

CVS-Specific Properties

These properties are only used for CVS working copies.

Subversion-Specific Preferences

These properties are only used for Subversion working copies.

Example

A basic all-in-one properties file for a project named "myproject trunk":

pulse.url=http://build.example.com:8080
pulse.user=jblogs
pulse.password=secret
project=myproject trunk
svn.username=jblogs
svn.password=mysecret