THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
| Table of Contents |
|---|
What is Gerrit?
The Impala project uses Gerrit for all our code reviews. Gerrit is a git-based code review tool. The Impala project Gerrit server is here.
...
You will need to authorize Gerrit to access some details of your Github account, and then you should be brought back to the Gerrit homepage. Unfortunately, there's a bug in the Gerrit OAuth plugin that will send you to a page that gives a 404 error. You'll need to manually go back to https://gerrit.cloudera.org/, and at that point you should be signed in as 'Anonymous Coward (X)'.
If your Gerrit username is different than your username on the system you want to send patches from, set your "GERRIT_USER" environment variable to your Gerrit username.
Add your public SSH key
Once you are logged in, click your user name in the top-right corner, and go to 'Settings'. Under 'SSH Public Keys' you'll need to paste in your public key:
...
Gerrit works by keeping a Git repository for all the projects it maintains, including Impala. In actual fact, this repository is in some sense the 'The source of truth ' for the Impala project, as all other repositories, including Impala's Github repository, are mirrors replicated from Gerrit.what is in Impala is the official Apache git server. Gerrit serves as a staging ground for reviewing patches, and once a patch is approved, a sort of waiting room while patches wait for a committer to officially move them to the Apache git repo.
Sending Submitting a patch to Gerrit is therefore exactly the same as 'pushing' a sequence of commits to a remote Git repository:
git push --no-thin asf-gerrit HEAD:refs/for/master
To set up Gerrit as a git remote for your Impala repository, do the following:
| Code Block |
|---|
cd ${IMPALA_HOME}
git remote add asf-gerrit ssh://<your-github-username>@gerrit.cloudera.org:29418 |
...
/Impala-ASF |
If using HTTP to connect to Gerrit, use the following command to add the Gerrit remote is also works:
| Code Block |
|---|
git remote add asf-gerrit http://<your-github-username>@gerrit.cloudera.org:8080/a/Impala-ASF |
Pay attention, when using HTTP to push/pull code, we need to input username/password. Do not use login account directly, we should get username/password from "Settings→HTTP Password" instead.
Sending a patch for review
...
Install the Gerrit pre-commit hook
...
| Warning |
|---|
Do not push directly to asf- |
...
Sending a patch for review
To submit send a patch for review, you should push it to a Gerrit-specific 'branch' on the Gerrit remote. That branch has the form form refs/for/<branch-name>. That patch will then be visible to code reviewers, who will review your code before it becomes part of Impala. If you want to see what a patch looks like without making it visible to code reviewers, push to the branch refs/drafts/<branch-name>. For the vast majority of patches the target branch will be master, which is where all mainline development happens. During releases, release managers may push commits to a specific release branch, however most new development will happen on master.
One thing to note is that Gerrit will submit all patches between the HEAD of the target branch and your current branch's HEAD for review. So:
In the example below, we're pushing HEAD to be a draft change. Gerrit provides a URL for the review.
| Code Block |
|---|
$ git push asf-gerrit HEAD:refs/ |
...
drafts/master
Counting objects: 3, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 332 bytes | 0 bytes/s, done.
Total 3 (delta 2), reused 0 (delta 0)
remote: Resolving deltas: 100% (2/2)
remote: Processing changes: new: 1, refs: 1, done
remote:
remote: New Changes:
remote: http://gerrit.cloudera.org:8080/8335 test [DRAFT]
remote:
To ssh://XXXX@gerrit.cloudera.org:29418/Impala-ASF |
Visit the URL that Gerrit provided to review the diff before sending it out to reviewers. Check that you've uploaded the right commit and that you've included what you wanted in the diff. When you've reviewed it yourself, hit the "Publish" button (
) to send the review to the community. This will make the review visible, but it won't be an official part of the Impala code base yet.
Note that Gerrit will send all patches between the HEAD of the target branch and your current branch's HEAD for review. Please
...
... will push all commits between asf-gerrit/master and your HEAD. Please therefore make certain that you are only pushing the commits you want reviewed: every separate commit translates to an e-mail in everyone's inbox!
...
Verifying a patch (open to all Impala contributors)
| Note |
|---|
The following does not apply if changes are only within the |
The following Jenkins jobs are available to all Impala contributors for testing patches they submit to Gerrit.
- pre-review-test: Use this to compile Impala and run, if desired, tests or test subsets.
bin/run-all-tests.shin the source tree is the best place to understand the meanings to the options of this job. - gerrit-verify-dryrun-external (new September 2017): Use this to run the full set of verifications, including multiple compilations of Impala using various build tools, and execution of all backend tests, frontend tests, core end-to-end tests, and Apache RAT verification. This is a wrapper around what a committer will ultimately run for you to verify and submit your patch (gerrit-verify-dryrun).
Neither of these jobs write a comment or Verified bit or attempt to Submit a Gerrit patch set. A submitter ought to monitor his or her job as it progresses. A submitter is encouraged to manually link a successful job in a Gerrit review comment as demonstration of success. When testing a draft, the "Impala Public Jenkins" user needs to be added to the change, so that Jenkins can access it.
Verifying and submitting a patch (Impala committers only
...
)
Once a change has a +2 from a committer and no -1 from any committer, it is ready to be verified and merged to gerrit. Remember that the source of truth for what is in Impala is the official Apache git server. Gerrit serves as a staging ground for reviewing patches, and once a patch is approved, a sort of waiting room while patches wait for a committer to officially move them to the Apache git repo.
To verify a patch, we use one of two different automated processes. Both are restricted to use by committers. If you are not a committer and your patch has been +2ed, please ask a committer to run the verification for you.
First, log in to https://jenkins.impala.io. If you are a committer and forgot your password, ask dev@impala.apache.org for help. Someone will reset your password.
Then, if your commit changes only files in the docs/ folder:
- Go to https://jenkins.impala.io/job/gerrit-docs-submit/build?delay=0sec. Put your gerrit patch URL in the PATCH_URL field. Leave the other fields with their default values. Press "Build".
- If all goes well, you will see messages like "Build started: https://jenkins.impala.io/job/gerrit-docs-submit/4/" and "Verified+1" and "Change has been successfully cherry-picked as 84ee40428dbb18146760adec8c5a03559f527ddb by Impala Public Jenkins" on your patch.
- If something breaks, go to the URL Jenkins posted to your patch. It will look something like this: https://jenkins.impala.io/job/gerrit-docs-submit/10/. Click on the "Build Artifact" and "Console Output" to look at the logs and figure out what went wrong.
If your commit doesn't change any files in the docs/ folder:
- Go to https://jenkins.impala.io/job/gerrit-verify-dryrun/build?delay=0sec. Put your gerrit patch URL in the PATCH_URL field. Leave the other fields with their default values. Press "Build".
- If all goes well, you will see messages like "Build started: https://jenkins.impala.io/job/gerrit-verify-dryrun/151/" and "Verified+1" and "Change has been successfully cherry-picked as 84ee40428dbb18146760adec8c5a03559f527ddb by Impala Public Jenkins" on your patch.
- If something breaks, go to the URL Jenkins posted to your patch. It will look something like this: https://jenkins.impala.io/view/Gerrit/job/gerrit-verify-dryrun/141/. Click on the "Build Artifact" and "Console Output" to look at the logs and figure out what went wrong.
If your commit touches files both in and out of the docs/ folder, run https://jenkins.impala.io/job/gerrit-verify-dryrun/build?delay=0sec first, following the directions above. Once it succeeds, run https://jenkins.impala.io/job/gerrit-docs-submit/build?delay=0sec.
| Tip |
|---|
Verifying and cherry-picking a patch can be simplified with a bookmarklet. Here is how to do that in Chrome:
By changing the javascript URL, you can also make a bookmarklet for the docs Jenkins job. |
When Jenkins has completed successfully, your change is in the master gerrit repo, but not yet in the official Apache repo. Apache does not allow non-sentient robots like Jenkins to submit patches. To get your patch to the official Apache repo, a committer has been verified by a pre-merge verification run, it can be submitted to gerrit. Once it is in is gerrit, a committer needs to push the commit to the Apache git repository, by running:
...
| Code Block |
|---|
bin/push_to_asf.py |
push_to_asf.py checks the latest commits in gerrit and checks if they are in the Apache git repo. If some are not in the Apache git repo yet, it will ask you if you want to update the Apache git repo with the missing commits found in the Gerrit repo. It does not check what your local state is at all. It only compares remote Gerrit with the remote Apache repo. Keep in mind that if you are a committer, it will allow you to commit any change authored by anyone that has passed
GVOthe Jenkins cherry-picking described above.
Creating a branch (Impala committers only)
According to project bylaws, branch creation is by lazy consensus of the PMC. We recommend that you email the dev mailing list to let people know about your branch so they understand its purpose.
The steps to create a branch are:
- Create the branch in gerrit: https://gerrit.cloudera.org/#/admin/projects/Impala-ASF,branches . You need to enter the branch name and the commit you want the branch to be based on (e.g. master if you're branching from master).
- Fetch the branch from gerrit and push it to the ASF Impala repository
| Code Block |
|---|
git fetch asf-gerrit
git checkout -b the-new-branch asf-gerrit/the-new-branch
git push apache HEAD:the-new-branch
|
Once the branch is created in both gerrit and the ASF repository, all commits should go to gerrit first, then be pushed to the ASF repository with push_to_asf.py.
Git and Gerrit etiquette
Contribution guidelines
Before you submit send a patch, please make sure that you've read the contribution guidelines.
...
As described above, Gerrit generates one review request per new commit. It's much easier to review everything related to a patch together in one single commit, so please make sure to squash all your related commits together before submittingsending. If you don't, your review requests will probably get forcibly removed
Other Useful Tools and Information
...
By default, git-review will look for a remote named 'gerrit'. The usage is:
| Code Block |
|---|
# SubmitSend a code review (or update an existing review). This will also do a git rebase -i asf-gerrit/master. git review -r asf-gerrit |
...