...
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
...
To 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> or refs/for/<branch-name>
. Use the draft form to review the change yourself, or use the "for" form to publish the review to the community immediately. 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
.
...
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 communityreview 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!
...
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.
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 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 the Jenkins cherry-picking described above.
...