Install StarTeam client on build machine

In order to use StarTeam repository, you will need to install StarTeam client on QuickBuild server and all build agents interacting with StarTeam repository. After installation, please copy the StarTeam API library file (normally starteamXX.jar, where XX stands for StarTeam API version) to the libs sub folder under QuickBuild server's installation directory.

Define StarTeam repository

StarTeam repository can be defined by choosing the StarTeam menu item from the repository menu as follows:

If you cannot find the StarTeam menu item, it probably means that StarTeam plugin has been disabled on plugin management page.
Please make sure clock of the build server and all build agents interacting with StarTeam repository are synced with the StarTeam server.

Proof build support

For general concept of proof build, refer to proof build. Here we explain how to set up StarTeam repository to support proof build.

Test proof build as administrator

Since proof build set up is a bit tricky, we first set up proof build for the administrator account and make sure it works before we proceed to enable it for all developers. To set up proof build for administrator, please follow below steps:

1. Login as administrator and download user agent by switching to My tab.
2. Install and start user agent on your own desktop. For testing purpose, please start the agent as a foreground process. On windows, this can be done by running agent.bat; on Unix platforms, this can be done by running agent.sh console
3. Set up a test configuration on QuickBuild server, and define a StarTeam repository and enable the proof build option like below:
   
4. Add a repository/checkout step into step execution graph and have it checkout from the repository defined above.

Now proof build has been enabled for your account, please try to checkout and edit some files in working view specified above, and then run the test configuration. If set up correctly, your local change will be picked up and reflected in the build result. A local change tab will also appear to display your uncommitted changes after build finishes. Your uncommitted changes will be committed automatically if build is successful.

Enable proof build for all developers

Now that we have a concept of how proof build works. In order to get proof build works for all developers, we need to parameterize property Working View, Root Relative Path, User Name and Password when define proof build support section of the repository, so that different values can be used for different developers. There are two approaches for this:

1. Define configuration variables representing these properties and have them prompt for values when the configuration is manually triggered. For example, we may define below variables:
   
   And then we can script property Working View, Root Relative Path, User Name, and Password in proof build section to take value of these variables as below:

   Property	Value
   Working View	${vars.get("workingView")}
   Root Relative Path	${vars.get("relativePath")}
   User Name	${vars.get("user")}
   Password	${vars.get("password")}

   In this way, these properties will be prompted when your developer run the build. Once they have been input by your developer for the first time, the value will be remembered for subsequent triggers for that user.

2. The second approach is to define user attributes in user agent nodes, and script the above properties to take value of those attributes. For example, you tell your developers to install user agent and define the user attribute workingView, relativePath, user and password through their user agents, and reference these attributes by writing property Working View, Root Relative Path, User Name and Password as:

   Property	Value
   Working View	${node.getAttribute("workingView")}
   Root Relative Path	${node.getAttribute("relativePath")}
   User Name	${node.getAttribute("user")}
   Password	${node.getAttribute("password")}