{note} Please make sure clock of the build server and all build agents interacting with StarTeam repository are synced with the StarTeam server.{note}
h1. 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 _plugins/com.pmease.quickbuild.libs_ sub folder under QuickBuild server's installation directory.
h1. {anchor:proof build}Proof build support
For general concept of proof build, refer to [proof build|Working with Proof Build]. Here we explain how to set up StarTeam repository to support proof build.
h3. 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:
# Login as administrator and download user agent by switching to _My_ tab.
# 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_
# Set up a test configuration on QuickBuild server, define a StarTeam repository, and enable the proof build option in advanced section like below:
!enable-starteam-proofbuild.png!
# 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.
h3. 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 various proof build properties, so that different properties can be used for different developers. To do this, you will need to:
# Define configuration variables like below:
!starteam-variables.png!
# Script various properties in proof build section to make use of above variables like below:
||Property Name||Property Value||
|Working View|$\{vars.get("workingView")\}|
|User Name|$\{vars.get("userName")\}|
|Password|$\{vars.get("password")\}|
|Checkin Condition|build.successful && vars.get("checkin").asBoolean()|
|Checkin Comment|$\{vars.get("comment")\}|
In this way, various proof build properties will be prompted when your developer run the build. Once they've been input by your developer for the first time, the values will be remembered for subsequent triggers for that user.
At last we suggest to set up the configuration to [enable concurrent builds|Build Concurrency and Deadlock] so that multiple builds in the same configuration can run concurrently. This is vital to get fast feedback in case multiple developers are requesting proof builds in the same time.
h1. 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 _plugins/com.pmease.quickbuild.libs_ sub folder under QuickBuild server's installation directory.
h1. {anchor:proof build}Proof build support
For general concept of proof build, refer to [proof build|Working with Proof Build]. Here we explain how to set up StarTeam repository to support proof build.
h3. 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:
# Login as administrator and download user agent by switching to _My_ tab.
# 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_
# Set up a test configuration on QuickBuild server, define a StarTeam repository, and enable the proof build option in advanced section like below:
!enable-starteam-proofbuild.png!
# 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.
h3. 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 various proof build properties, so that different properties can be used for different developers. To do this, you will need to:
# Define configuration variables like below:
!starteam-variables.png!
# Script various properties in proof build section to make use of above variables like below:
||Property Name||Property Value||
|Working View|$\{vars.get("workingView")\}|
|User Name|$\{vars.get("userName")\}|
|Password|$\{vars.get("password")\}|
|Checkin Condition|build.successful && vars.get("checkin").asBoolean()|
|Checkin Comment|$\{vars.get("comment")\}|
In this way, various proof build properties will be prompted when your developer run the build. Once they've been input by your developer for the first time, the values will be remembered for subsequent triggers for that user.
At last we suggest to set up the configuration to [enable concurrent builds|Build Concurrency and Deadlock] so that multiple builds in the same configuration can run concurrently. This is vital to get fast feedback in case multiple developers are requesting proof builds in the same time.