Skip to main content
Version: QB14

Working with Perforce

Specify p4 command location​

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

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

  1. Open Perforce plugin setting page and define the p4 path property as:

    ${node.getAttribute("p4Path")}

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

    In case of user agent node, the user attribute need to be defined [in this way](Manage User Agent.html#ManageUserAgent-defineuserattributes).

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

Proof build support​

For general concept of proof build, refer to proof build. Here we explain how to set up Perforce 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 Perforce repository, and enable the proof build option in advanced section like below:
  4. Make sure the p4 command exist in the system path of both server machine and your desktop. If not, please follow the section Specify p4 command location to tell QuickBuild location of p4 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 checkout and edit some file in the local perforce client 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.

{#WorkingwithPerforce-proofbuildforalldevelopers}

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 NameProperty Value
    Local Client${vars.get("localClient")}
    User Name${vars.get("userName")}
    Password${vars.get("password")}
    Sync Conditionvars.get("sync").asBoolean()
    Change Numbers to Verify${vars.get("changeLists")}
    Submit Conditionbuild.successful && vars.get("submit").asBoolean()
    Submit 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 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.

Shelve support​

The proof build mechanism serves the purpose of verifying unsubmitted changes, but it requires developers to install user agent on their development machine. Also it requires that the user agent is online when proof build is finished, which is not ideal as it is impossible for developer to submit proof build and then shutdown computer to go home. The perforce shelve support in QuickBuild 5.1 comes to rescue. It serves the same purpose of verifying unsubmitted changes, without aforementioned limitations. What it does is to merge shelved changes with latest version in defined repository, run build, and optionally submit shelved changes if build is successful.

To enable perforce shelve support, tick the option Merge with Shelved Changes in advanced setting of perforce repository like below:

Just like what we've done when enable proof build for all developers, we can enable shelve support for all develoers with help of variables:

  1. Define variables as below to prompt developer for perforce account and shelved change lists when the configuration is triggered:
  2. Script various properties in shelve support definition to make use of above variables:

    With this, you no longer need to hard code shelve account/change list information at the time defining shelve support. Developer will be prompted with below screen at the time triggering the configuration:

Lastly, if you select to submit the changes in shelve support, QuickBuild will submit the shelved changes and the shelved changes will be removed from developer's local client.

Last updated on