Page History

...

To set up Gerrit as a git remote for your Impala repository, do the following:

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:

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

Gerrit keeps track of different patches by generating a unique Change-Id that is constant over all iterations of a patch (obviously the Git hash won't do, since that changes every time the patch changes). That Change-Id is appended to every commit message:

IMPALA-1726: Move JNI / Thrift utilities to separate header

To avoid pulling in jni.h in the codegen module (where it does not
compile), this patch moves the methods that depend on both Thrift and
JNI to a separate header where it can be included more precisely.

Change-Id: I4d97f1816b24149d9163dce59f31b2afe2642b11

Gerrit provides a "pre-commit hook" that automates Change-Id generation. Installing it is very easy:

cd ${IMPALA_HOME}
curl -o .git/hooks/commit-msg https://gerrit.cloudera.org/tools/hooks/commit-msg
chmod u+x .git/hooks/commit-msg

After the hook is installed, every commit you make will get its own Change-Id. Without it, Gerrit will reject all patches.

Rebase Your Branch

Commit all outstanding changes:

cd $IMPALA_HOME
git add --update
git commit

Rebase against asf-gerrit/master (good practice to catch conflicts introduced by recent commits)

git fetch asf-gerrit
git rebase asf-gerrit/master

You might have to resolve merge conflicts during 'git rebase'. Follow the instructions, then continue with

git rebase --continue

Squash everything down to a single commit:

git rebase -i asf-gerrit/master

Make sure to pick only the first commit and 's' (squash) following lines, then edit the commit message into something coherent. Run the git log command to see that you're exactly one commit ahead of asf-gerrit/master

branch-master() {
  git fetch asf-gerrit && git checkout -b $1 asf-gerrit/master
}
alias "rebase-master"="git fetch asf-gerrit && git rebase -i asf-gerrit/master"

Sending a patch for review

To send a patch for review, you should push it to a Gerrit-specific 'branch' on the Gerrit remote. That branch has the 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.

In the example below, we're pushing HEAD to be a draft change. Gerrit provides a URL for the review.

$ 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 (Image Added) 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 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!

...

Sending a patch for review

Install the Gerrit pre-commit hook

Gerrit keeps track of different patches by generating a unique Change-Id that is constant over all iterations of a patch (obviously the Git hash won't do, since that changes every time the patch changes). That Change-Id is appended to every commit message:

IMPALA-1726: Move JNI / Thrift utilities to separate header

To avoid pulling in jni.h in the codegen module (where it does not
compile), this patch moves the methods that depend on both Thrift and
JNI to a separate header where it can be included more precisely.

Change-Id: I4d97f1816b24149d9163dce59f31b2afe2642b11

Gerrit provides a "pre-commit hook" that automates Change-Id generation. Installing it is very easy:

cd ${IMPALA_HOME}
curl -o .git/hooks/commit-msg https://gerrit.cloudera.org/tools/hooks/commit-msg
chmod u+x .git/hooks/commit-msg

After the hook is installed, every commit you make will get its own Change-Id. Without it, Gerrit will reject all patches.

Rebase Your Branch

Commit all outstanding changes:

cd $IMPALA_HOME
git add --update
git commit

Rebase against asf-gerrit/master (good practice to catch conflicts introduced by recent commits)

git fetch asf-gerrit
git rebase asf-gerrit/master

You might have to resolve merge conflicts during 'git rebase'. Follow the instructions, then continue with

git rebase --continue

Squash everything down to a single commit:

git rebase -i asf-gerrit/master

Make sure to pick only the first commit and 's' (squash) following lines, then edit the commit message into something coherent. Run the git log command to see that you're exactly one commit ahead of asf-gerrit/master

branch-master() {
  git fetch asf-gerrit && git checkout -b $1 asf-gerrit/master
}
alias "rebase-master"="git fetch asf-gerrit && git rebase -i asf-gerrit/master"

Sending a patch for review

To send a patch for review, you should push it to a Gerrit-specific 'branch' on the Gerrit remote. That branch has the form refs/for/<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 send all patches between the HEAD of the target branch and your current branch's HEAD for review. So:

git push --no-thin asf-gerrit HEAD:refs/for/master

... 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!

Testing your configuration

If you want to check that you set up gerrit correctly, you can

git push --no-thin asf-gerrit HEAD:refs/drafts/master

This will push a patch that only you can see. When you see it has worked, you can click "Abandon" on it in the web interface.

Verifying a patch (open to all Impala contributors)

...

The following Jenkins jobs are available to all Impala contributors for testing patches they submit to Gerrit.

1. pre-review-test: Use this to compile Impala and run, if desired, tests or test subsets-test: Use this to compile Impala and run, if desired, tests or test subsets. bin/run-all-tests.sh in the source tree is the best place to understand the meanings to the options of this job.
2. gerrit-verify-dryrun-external (WIP; coming soonnew September 2017): Use  Use this to run the full set of verifications, including a compile 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, and more. This is a wrapper around what a committer will ultimately run for you to verify and submit . This omits the submission phaseyour 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)

...

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. 

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 needs to push the commit to the Apache git repository, by running:

...

bin/push_to_asf.py

...