preface

As a code review tool, Gerrit provides flexible control over code reviews and operations such as Merge. If you can combine review with continuous integration in Gerrit, you can significantly improve code quality. This paper mainly introduces the integration of Gerrit and Jenkins, endows Jenkins’ ability to automate tasks with Gerrit, and carries out automatic inspection in every stage from code submission to integration.

Jenkins plug-in installation and configuration

1. Install

Go to “System Management -> Management Plug-ins -> Optional Plug-ins”, search for the plug-in Gerrit Trigger, and click install.

2. The configuration

Choose System Administration > Gerrit Trigger, add Gerrit Server, configure it as shown in the following figure, and then test the connection.

  • Name: Name of the
  • Hostname: indicates the server domain name or IP address
  • Frontend URL: Indicates the Gerrit UI address
  • SSH Port: Indicates the SSH Port. Gerrit is 29418 by default
  • Username: indicates the Username used to connect to Gerrit
  • SSH Keyfile: The Jenkins server’s private key path, and the Jenkins public key needs to be configured into the Gerrit user’s public key list above
  • SSH Keyfile Password: specifies the Password of the private Keyfile

If you want to display the results of Jenkins’ builds into Gerrit, you need to configure the REST API in advanced. As shown in the figure below, the test is available after the configuration is complete:

  • Gerrit HTTP Username: indicates the user in Gerrit
  • Gerrit HTTP Password: Gerrit password. Need to be selected in Gerrit UI’s user SettingsHTTP PasswordTo generate an HTTP password.

Jenkins task configuration

After Jenkins plug-in configuration is completed, create Jenkins task and perform the following configuration:

Source configuration

  • Repository URL: Gerrit source code download address
  • Credentials: authentication for downloading source code. This parameter can be null if the public key of Jenkins’ machine has been configured to the Gerrit user
  • Name: ID of the repository, such as Origin, which is used to uniquely identify the repository among other remote repositories. This is the same “name” you used in git remote. If left blank, Jenkins will generate a unique name for you. You usually want to specify this option when you have multiple remote repositories.
  • Refspec: The Refspec controls the remote references to retrieve and how they map to local references. If left blank, it will be for git fetch normal behavior consistent recognition, it will be all the branch heads retrieval for the remotes/REPOSITORYNAME/BRANCHNAME. For most cases, this default behavior will work. In other words, the default refspec is “+ refs/heads / * : refs/remotes/REPOSITORYNAME / *”, including REPOSITORYNAME is you in the name of “repository” above the value specified in the text box.
  • Branches to Build: If you want to track specific Branches in the repository, specify Branches. If left blank, all branch changes are checked and built. The safest way is to use refs/heads/ syntax. Thus the expected branch is clear.
  • When you are interested in building multiple heads (most commonly branches) using job, you can choose how Jenkins chooses branches to build in what order. This extension point in Jenkins is used by many other plug-ins to control jobs to build specific commits. When you activate these plug-ins, you may see them installing custom policies here.

To get Git plug-ins to download your changes, set Refspec to $GERRIT_REFSPEC, And set Additional Behaviours To Additional Behaviours/Strategy For Choosing What To Build and select GERRIT Trigger. You may also need to set Branches to build to $GERRIT_BRANCH.

If this doesn’t work for you please set Refspec to refs/changes/*:refs/changes/* and Branches to build to $GERRIT_REFSPEC.

Gerrit Trigger configuration

Gerrit Project: configure the monitoring code base. Configure the monitoring branch on the right. For details, please click question mark.

Trigger on: Specifies the type of event to fire.

  • PatchSet created: when uploading a new change or PatchSet (default if Trigger on is null)
  • Draft Published: When a change or patch set is published (default when Trigger on is empty)
  • Change abandoned: When a Change is abandoned
  • Change merged: When changes merge/commit
  • Change restored: changes restored triggers when changes were restored
  • Comment Added: When the specified voting category and value have review content
  • Reference updated: When a Reference (such as a branch or tag) is updated

other

After the preceding configuration is complete, configure other items such as the scripts to be executed. After the monitored branch is modified, Jenkins task will be automatically triggered for execution.