We need to define a Jenkins job to fetch the code from Gerrit and build it in the Continuous Integration environment. Additionally, we may want to disable all of the post validation phases except unit tests, in order to shorten the build execution time. Remember that this job will be triggered much more frequently than a typical Continuous Integration job.
We need to change the conditions for triggering a new build on the job from SCM polling (or other trigger policy) to Gerrit event. Additionally, we also need to specify the Gerrit conditions for the trigger action, available when clicking on the Advanced button in the Gerrit trigger specific configuration section.
The additional parameters needed are project name (specified as a plain complete text string) and branches (specified as the path regular expression **).
Finally, we need to tell the Git plugin how to get the source code from the Gerrit trigger plugin. This inter-plugin communication happens through environment variables: Gerrit defines two variables ($GERRIT_REFSPEC and $GERRIT_PATCHSET_REVISION) populated respectively with the Gerrit ref-spec to fetch and the actual Change patch-set to be checked out.
We need then to edit the Git repository settings (by clicking on the Advanced button) in the following way:
Set
$GERRIT_REFSPECas the Git refspec to cloneSet
$GERRIT_PATCHSET_REVISIONas the Git branch to buildSet the choosing strategy to Gerrit trigger
We suggest that you enable two additional flags:
Wipe out workspace: Potentially each build could fetch a completely different branch of the code, without wiping out the workspace; we may risk relying on temporary files generated from previous builds.
Use shallow clone: Changes are typically well-defined unique snapshots of code; having the entire clone history on the local file system would not help and just increases the amount of disk space used.
These flags are not necessarily needed, but are strongly recommended for preventing future headaches when fetching and building multiple changes.