changes.
| | h1. Specify cleartool command location |
| | |
| | QuickBuild utilizes the cleartool command to interact with ClearCase. If this command is not in system path, you will need to specify location of the command by configuring ClearCase plugin as below: |
| | !clearcase2.png! |
| | |
| | Further more, Cleartool location can be specified on a per-node basis by following below steps: |
| | # Open ClearCase plugin setting page and define the cleartool path property as: |
| | {code} |
| | ${node.getAttribute("cleartoolPath")} |
| | {code} |
| | # For each node that does not have cleartool on system path, define the user attribute _cleartoolPath_ to point to the actual cleartool path like below: |
| | !cleartool-path.png! |
| | |
| | Please note that in above example, the _cleartoolPath_ user attribute is just for demonstration purpose. You can use any other user attribute name. |
| | |
| | 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 ClearCase 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, and define a ClearCase repository and enable the proof build option like below: |
| | | # Set up a test configuration on QuickBuild server, and define a ClearCase repository and enable the proof build option in advanced section of the repository like below: |
| | !clearcase4.png! |
| | # Make sure the cleartool command exist in the system path of both server machine and your desktop. If not, please follow the section _Specify cleartool command location_ to tell QuickBuild location of cleartool command. |
| | # 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 inside the local view path 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: |
| | !variable1.png! |
| | # Script various properties in proof build section to make use of above variables like below: |
| | ||Property Name||Property Value|| |
| | |Local View Path|$\{vars.get("localViewPath")\}| |
| | |Update Condition|vars.get("update").asBoolean()| |
| | |Checkin Condition|build.successful && vars.get("commit").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 change run mode of the proof build configuration so that multiple builds can run concurrently in order to get fast feedback in case multiple developers requesting proof build in the same time. Run mode of the configuration can be changed by editing basic setting of the configuration. |
| | |
| | h1. Limitations |
| | Please be aware of below limitations when use this repository: |
| | # Directory operations, file deletions and file renamging in ClearCase are not detected as changes due to limitation of the cleartool command. |
| | # Newly branched files are detected as added files. |
| | # Changes are only detected on current branch. For example, if file1 goes through version _main/2_, _main/3_, _main/branch1/1_, _main/branch1/2_ between two builds, only changes for _main/branch1/1_ and _main/branch1/2_ are detected. |
Working with ClearCase