Accurev relies heavily on accurate system clock to perform its operations. Please make sure clock of the build server and all build agents interacting with Accurev repository are synced with Accurev server.

Specify Accurev command location

QuickBuild utilizes the accurev command to interact with Accurev SCM. If this command is not in system path, you will need to specify location of the command by configuring Accurev plugin as below:

Further more, accurev command location can be specified on a per-node basis by following below steps:

1. Open Accurev plugin setting page and define the accurev path property as:

   ${node.getAttribute("accurevPath")}
   

2. For each node that does not have accurev on system path, define the user attribute accurevPath to point to the actual accurev path like below:
   

Please note that in above example, the accurevPath user attribute is just for demonstration purpose. You can use any other user attribute name.

Change detection

If the build process involves checking out from a Accurev repository, the changes will be detected for the build stream and all parent streams until a snapshot or time-locked parent is found.

Label a Accurev repository

The label step will create a snapshot stream backed by the build stream, with the snapshot name set to label name.

Proof build support

Proof build support can be enabled to send active changes from developer's local workspace to QuickBuild for build verification. For general concept of proof build, refer to proof build. Here we explain how to set up Accurev 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, define a Accurev repository, and enable the proof build option in advanced section like below:
   
4. Make sure the Accurev command exists in the system path of both server machine and your desktop. If not, please follow the section Specify Accurev command location to tell QuickBuild location of Accurev command.
5. 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 edit some file and keep them in the local Accurev workspac specified above, and then run the test configuration. If set up correctly, your local active change will be picked up and reflected in the build result. A local change tab will also appear to display your active changes after build finishes. Your active changes will be promoted 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 various proof build properties, so that different properties can be used for different developers. To do this, you will need to:

1. Define configuration variables like below:
   
2. Script various properties in proof build section to make use of above variables like below:

   Property Name	Property Value
   Local Workspace	${vars.getValue("localWorkspace")}
   User Name	${vars.getValue("userName")}
   Password	${vars.get("password")}
   Promote Condition	build.successful && vars.get("promoteIfSuccessful").asBoolean()
   Promote Comment	${vars.get("promoteComment")}

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