changes.
| |  | QuickBuild integrates with Gerrit via the Gerrit repository to verify gerrit changes. |
| | | QuickBuild integrates with Gerrit via the Gerrit repository to verify gerrit changes. To build against Gerrit changes, define a Gerrit repository like below: |
| | !gerrit_repo.png! |
| | |
 | | h2. Build against gerrit changes |
| | | And then add a checkout step in your step workflow to check out that repository, followed by appropriate build/test steps to verify checked out code. Upon initial triggering of the configuration containing this checkout step, QuickBuild will call Gerrit RESTful API to spawn a build request for each open change (or open change of specified branch if branch is specified in gerrit repository). Subsequent triggering of the configuration will only spawn build request for new change and change with new patch sets. In order to provide fast feedback of the changes, please make sure the configuration can run concurrently by enable concurrent mode in general setting of the configuration, and then configure node selection of the master step so that different build requests can run on different build agents. |
| | |
| | To build against Gerrit changes, define a Gerrit repository like below: |
| | |
| | !repository.png! |
| | |
| | In repository definition, you may select to build against open, closed, or specified pull requests, and choose to build head, merge, or both of selected build requests like below: |
| | !pull_requests.png! |
| | Here _head_ branch of pull request points to tip commit of the pull request, while _merge_ points to merged commit of head commit and tip commit of target branch of the pull request. After defining the Git repository, you should add a checkout step to check it out into the workspace, and add necessary build steps to build against checked out contents. |
| | |
| | Upon triggering of configuration using such repository, QuickBuild will first find all matched pull requests at GitHub side and then fire separate build request(s) for each pull request to check changes against that pull request, and build that pull request if necessary. So if there are many matched pull requests, many build requests will be fired. So it is best practice to enable [concurrent build|Build Concurrency and Deadlock] to speed up verification of multiple pull requests. |
| | |
| | As demonstrated below, each finished build will display associated pull request as branch information and changes of the build will be calculated against previous build with the same pull request branch. |
| | !branch.png! |
| | |
| | Upon manual triggering of such configuration, all matched pull requests will be built even if they've not being updated, just like what QuickBuild behaves when trigger configurations using normal repositories. However if you schedule the configuration and set build condition to _If changes found in referenced repositories_ (or something similar), QuickBuild will only build against new/updated pull requests. |
| | |
| | h2. Update pull request status at GitHub side based on build status |
| | |
| | When build against *head branch* of GitHub pull requests, QuickBuild will update pull request status automatically to reflect build status when build is started/finished, as demonstrated below: |
| | !verifying_pullrequest.png! |
| | !verified_pullrequest.png! |
| | |
| | {note}To make this working, make sure head branch of relevant pull requests are getting built as pull request status reflects head commit status.{note} |
| | | After build finishes, QuickBuild will update relevant changes Gerrit server with the build information including build url. Further, if label scoring is enabled when define Gerrit repository, QuickBuild will score specified Gerrit label based on build status like below: |
| | !gerrit_server.png! |
Working with Gerrit