At the end of the tutorial, you will be at moderate level on how to use tool and can upscale from thereafter. Gerrit is used to manage Non-Java and Java projects and we assume you will be using it for both. If any knowledge on SDLC and web based application development is good to have. Gerrit Tutorial: List of Topics. A basic overview of the code review process under Gerrit vs GitLab. Been using Gerrit for several months at work now. It is slowly starting to grow on m. See how to use Gerrit Code Review on top of your existing GitHub projects. Learn how to import and replicate GitHub repositories and pull requests into Gerri. SSH stands for Secure Shell or sometimes Secure Socket Shell protocol used for accessing network services securely from a remote computer. You can set the SSH keys to provide a reliable connection between the computer and Gerrit. You can check the existing SSH key on your local computer using the following command in Git Bash −.
- Main Page
- Community portal
- Current events
- Recent changes
- Random page
- Page information
- Permanent link
- Printable version
- Special pages
- Related changes
- What links here
This wiki page describes how to contribute to the Eclipse project via Gerrit hosted at https://git.eclipse.org/r
Gerrit is a web based code review system, facilitating online code reviews for projects using the Git version control system. For more information about Gerrit, please see http://code.google.com/p/gerrit/.
- 3Gerrit setup
- 4Doing Code Reviews with Gerrit
- 4.1Using Gerrit with the git command line
- 5Gerrit Code Review Cheatsheet
Enabling Gerrit for your Eclipse.org Project
- File a bug and specify for which project you'd like to enable Gerrit
- Ask your Project Lead to +1 the request
- Select a date for project committers to update their repo URLs
- Choose one of the two options:
- I want project committers to use Gerrit code review exclusively for my project. Everything must be reviewed -- no direct access to the main repo should be available.
- I want project committers to be able to bypass the Gerrit code review system and push changes directly to the git repo. Please note that this will have to be done via the 'new' Gerrit URLs(SSH and HTTPS). The original dev.eclipse.org SSH URLs will become inactive once Gerrit is enabled.
- (see bug 413753 for a third option -- Eclipse Platform projects keep direct access to the Git repo)
- Note: If you're adding all of your code repos to Gerrit, you will lose control of the 'container' for your project(/gitroot/projectname), as Webmaster will give the container to the Gerrit user. This means that you will not be able to create new repos via the initrepo command, instead you will have to contact Webmaster(via a bug).
In order to contribute you need an Eclipse user account and to sign the Eclipse Contributor Agreement (ECA).
- Create an account with the Eclipse Foundation if you do not already have one;
- Click the Eclipse Contributor Agreement link on your account page; and
- Complete the form.
Be sure to use the same email address when you register for the account that you intend to use on Git commit records.
Gerrit Web UI
Logon to the Gerrit Web UI (see links below) using the email address you registered with your Eclipse Foundation account and password.
- Eclipse projects:
- PolarSys projects:
Git over SSH
When accessing Gerrit over SSH from git or EGit use the username displayed in your user settings (e.g eclipse.org Gerrit) and upload your public SSH key to Gerrit.
Upload keys for:
Gerrit Tutorial Meaning
- If you are absolutely certain you do not have keys already, you must create a public and private pair of SSH keys. It is strongly recommended that you use a passphrase.
- Generating SSH key pair on command line
- Execute SSH once to accept the host key (or copy it from the registration web page)
Gerrit push URLGerrit SSH URL:
Gerrit's SSH service listens on port 29418 and isn't linked to the public keys on git.eclipse.org used for SSH shell access on port 22
Git over HTTPS
When accessing Gerrit over HTTPS from git or EGit, use the username and password displayed on this page.
By default the password field is blank. You must create a password using the 'Generate Password' button.Gerrit HTTPS URL:
Be notified of upcoming changes
Enabling Gerrit notifications is as important as enabling Bugzilla's ones when you are contributor on a project. Here is the place where you can subscribe to Gerrit notifications: https://git.eclipse.org/r/#/settings/projects
Doing Code Reviews with Gerrit
After someone pushed a change you can start reviewing the changes.
- Visit the Eclipse Gerrit Code Review instance to start reviewing.
- Use Gerrit queries to filter the review list for changes you are interested in.
- Register to watch projects if you want to be notified by email on new or updated changes pushed for review.
- Adjust your Gerrit preferences to customize it to your needs.
- See the Gerrit user guide for more information about using Gerrit.
- The EGit tutorial walks you through the basic steps of working with Gerrit and EGit.
- Gerrit tutorial by Lars Vogel
Using Gerrit with the git command line
- Upload your patch from Git to the target project, where (project) is the project specifier as per the Gerrit Web UI and may include a prefix, eg cdt/org.eclipse.cdt.git:
Adding a dedicated remote
Since git can have multiple remotes, you can define one to be used to refer to Gerrit to save typing. Inside a previously checked-out repository you can run:
You can now submit review requests from either repository using:
Using Gerrit with EGit
Eclipse will look for your private key in the SSH2 Home location specified in the General>Network Connections>SSH2 Preference Page. If your
id_rsa private key makes use of the AES-128-CBC algorithm (view the file as text to confirm), Eclipse will need at least
com.jcraft.jsch 0.1.44 to make use of it.
- Afterwards open the Git Repositories view and select Gerrit Configuration... in the context menu of the remote 'origin' in the Git Repositories view to configure pushing to the code review queue.
- Alternative approach: Add a new review remote in the Git Repositories view and select Gerrit Configuration... in the context menu of the remote
- From the appropriate Remotes node, create a New Remote and choose to Configure for Push. A unique name should be chosen, review is suggested.
- Changes committed to your local clone can now be pushed to Gerrit using the review Remote. You will be prompted for your private key's passphrase if Eclipse is looking for it in the right place.
- Instead of using the Gerrit Configuration... wizard you can do the configuration steps manually:
- Change the main URI or Add a Push URI (your Gerrit user name must be used here)
- In the Ref mapping section, add a RefSpec specification of
- Visit our Gerrit Code Review instance to start reviewing
Using the Mylyn Gerrit Connector
The Mylyn Gerrit Connector can be installed from the Mylyn p2 repository, e.g. for juno from http://download.eclipse.org/mylyn/releases/juno.
It contains several useful features:
- Cloning from Gerrit and automatic configuration
- The wizards 'Import Projects from Git' and 'Clone Git Repository' will offer the possibility to browse the list of repositories on Gerrit servers and to clone selected repositories. After cloning the Gerrit configuration will be done automatically.
- Importing Gerrit changes as Mylyn tasks
- Fetching patch sets directly from the task editor
- Reviewing changes in the task editor
- Submitting changes from the task editor
Bypassing code review
In some cases it may be desirable to bypass code review. Your Gerrit-enabled project must be configured to allow bypassing code review. Please ask Webmaster if you are not sure.
Please see Denis' blog post outlining how to bypass code review.
Install the commit-msg hook in your repository
This will ask for a password. It is the password that you have to generate in the SSH Keys section of settings in your Gerrit account.
You can alternatively download the file or use curl to install it via https:
The hook helps append a Change-Id to your commit message.
EGit can also generate the Change-Id and can also be configured to automatically include it.
How To Use Gerrit
If something went wrong you should check your log entries like this:
Each commit should provide the necessary properties as required by the Gerrit configuration. Let's see this example (accessible in your account):
Depending on your settings 1 and 2 you must provide the corresponding values in your commit messages. So for this example the fields 'Change-Id' and 'Signed-off-by' are enabled which means that each commit must contain the following lines (just an example):
To create a new change
Or, if you've followed the instructions on Adding a dedicated remote you can simply do:
Since the current repository has the right definition for 'review', you won't need to remember the canonical push URL
To update an existing change with a new commit
This works because Gerrit links the new commit to the prior change based upon the Change-Id footer in the commit message. (This is automatically generated by the commit-msg hook you installed above.) If you refuse to use the commit-msg hook, or don't have a Change-Id footer, you should read the Gerrit documentation on change-id lines and replacing changes.
Note: To be picked up by Gerrit, a Change-Id line must be in the bottom portion (last paragraph) of a commit message, and may be mixed together with the Signed-off-by, Acked-by, or other such footers. So if your Change-Id line is ignored it's probably not in the last paragraph :).
To compare bulk diffs using Git
Since each Gerrit review patchset actually commits its own tree, you can pull out the trees and compare them.
If you've got a large changeset, and you want to be able to do diffs between them via (command line) git instead of browsing on the web, then you can fetch the individual changes and then perform a diff. For example, http://git.eclipse.org/r/2 shows the 'download' section for each patchset. In this case, it looks like:
- Patch Set 1
git pull ssh://[email protected]/jgit refs/changes/02/2/1 (1d3331a91bd477d3f70cde9613576cf9688ac358)
- Patch Set 2
git pull ssh://[email protected]/jgit refs/changes/02/2/2 (13ab9a43d4d512963556a92e889b1204d32f8e68)
- Patch Set 3
git pull ssh://[email protected]/jgit refs/changes/02/2/3 (d14cc645655683ba3e30a35833fb2282142e898f)
- Patch Set 4
git pull ssh://[email protected]/jgit refs/changes/02/2/4 (43de8d385b614c72fd796e17da75d381f6e0cc25)
git pull will both get the bits and merge them into your tree, which won't do what you want for comparison. So, in order to get the bits (but not merge), you need to do a
git fetch instead. Let's say we want to diff the last two patches against each other rather than reviewing the entire patchset again:
If you're doing this from within an already checked out project, you can do
git fetch origin (or any other remote name in
Git fetched data will stay around in your repository, but will be 'orphaned' if no references point to it. To clean up, you can run
git gc or wait until this happens automatically.
To approve a change
- Click on Publish Comments
- Vote with the radio buttons
To add a reviewer
Once you've pushed your commit to Gerrit for review, you can go to the web page (https://git.eclipse.org/r/) and see your changes. By clicking on the review, there's an option to add a reviewer by e-mail address; they'll then be sent a message indicating that they'd like your review on the item.
The code review category indicates your opinion on the quality of the code, and how well it fits within the purpose of the existing surrounding code. A +2 vote from any committer is required before submission can occur. A -2 vote from any committer will block submission.
Follow the rules given in Handling Git Contributions received via Gerrit.
Verifying Changes on Jenkins using Gerrit Trigger Plugin
Moved to Jenkins#Gerrit_Trigger_Plugin