THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
Gerrit works by keeping a Git repository for all the projects it maintains, including Impala. 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.
Submitting Sending a patch to Gerrit is therefore exactly the same as 'pushing' a sequence of commits to a remote Git repository:
...
cd ${IMPALA_HOME}
git remote add asf-gerrit ssh://<your-github-username>@gerrit.cloudera.org:29418/Impala-ASF
...
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 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 submit send all patches between the HEAD of the target branch and your current branch's HEAD for review. So:
...
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 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 http://jenkins.impala.io:8080. 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 http://jenkins.impala.io:8080/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: http://jenkins.impala.io:8080/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: http://jenkins.impala.io:8080/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 http://jenkins.impala.io:8080/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: http://jenkins.impala.io:8080/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: http://jenkins.impala.io:8080/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 http://jenkins.impala.io:8080/job/gerrit-verify-dryrun/build?delay=0sec first, following the directions above. Once it succeeds, run http://jenkins.impala.io:8080/job/gerrit-docs-submit/build?delay=0sec.
Once your patch is cherry-picked by Impala Public Jenkins 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 GVO.
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.
...
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 |
...