...
If you need to make changes you just need to push further changes to the branch - but keep in mind that any new commit will trigger a new testrun; and the time needed to execute tests is measured in hours - so keep this in mind when you are pushing in changes.
Creating a Patch
After you have committed a change or a set of changes to your local repository, you need to create a patch to post on the JIRA. The naming convention for patches is:
| Code Block |
|---|
HIVE-<JIRA-NUMBER>[.<patch-num>][.<branch-name>].patch |
<patch-num> is only required if it is not the first patch.
<branch-name> is only required if it is not master. (See 83527164 above.)
So the first patch for JIRA HIVE-9999 intended to be applied to master would be named "HIVE-9999.patch".
The second patch for the same JIRA would be named "HIVE-9999.2.patch".
A patch for the same JIRA intended to be applied to the branch-1 branch would be named HIVE-9999.branch-1.patch".
The following git command creates a patch:
| Code Block |
|---|
git diff --no-prefix <commit> > HIVE-1234.1.patch
|
<commit> is the last commit from Hive (not you) before your commits. Note that if it has been a while since you fetched or pulled from the Hive repository, you may need to do a rebase to get your commit(s) on top in order to create a patch that will cleanly apply.
Please do not:
- reformat code unrelated to the bug being fixed: formatting changes should be separate patches/commits;
- comment out code that is now obsolete: just remove it;
- insert comments around each change, marking the change: folks can use git to figure out what's changed and by whom;
- make things public which are not required by end users.
Please do:
- try to adhere to the coding style of files you edit;
- comment code whose function or rationale is not obvious;
- add one or more unit tests (see 83527164 above);
- update documentation (such as Javadocs including package.html files and this wiki).
Precommit Tests by Hive QA
If the name of your patch conforms to the naming convention shown above, the automated testing system will run precommit tests and post the results as a JIRA comment from Hive QA. The results give advisory +1 or -1 votes (SUCCESS or ERROR) based on whether all of the tests executed successfully and, more recently, whether existing tests are modified or new tests are included in the patch to cover the code changes. For examples, see the Hive QA comments on HIVE-9534 and HIVE-11752. Note that sometimes tests fail for reasons unrelated to the patch.
Patches with nonconforming names are ignored by Hive QA. One leading zero can be used in <patch-num>, such as "HIVE-9999.02.patch", but multiple leading zeros are not accepted (see comments on HIVE-12981).
To retest a patch, you can cancel it and resubmit it. These two status changes are not necessary for a new patch that has a different filename, but if the filename stays the same then Hive QA ignores the patch after its first test unless you cancel and resubmit.
To prevent precommit testing, include the case-sensitive phrase NO PRECOMMIT TESTS in the Description section of the JIRA issue. You can remove it later as needed. For examples, see HIVE-5289, HIVE-7343, and HIVE-7375.
Attaching and Submitting a Patch
This section only gives the basic procedures for attaching and submitting a patch. See 83527164 below for more information.
- Attach the patch file to a JIRA ticket: in the ticket's "More" tab, select "Attach Files" and use "Choose File" to upload the file, then add a descriptive comment.
- Put the patch in the review queue: click the "Submit Patch" button. The button name will change to "Cancel Patch" and the ticket status will change to Patch Available.
Updating a Patch
Please do not:
- reformat code unrelated to the bug being fixed: formatting changes should be separate patches/commits;
- comment out code that is now obsolete: just remove it;
- insert comments around each change, marking the change: folks can use git to figure out what's changed and by whom;
- make things public that are not required by end-users.
Please do:
- try to adhere to the coding style of files you edit;
- comment code whose function or rationale is not obvious;
- add one or more unit tests (see 83527164 above);
- update documentation (such as Javadocs including package.html files and this wiki).
Precommit Tests by Hive QA
If the name of your patch conforms to the naming convention shown above, the automated testing system will run precommit tests and post the results as a JIRA comment from Hive QA. The results give advisory +1 or -1 votes (SUCCESS or ERROR) based on whether all of the tests executed successfully and, more recently, whether existing tests are modified or new tests are included in the patch to cover the code changes. For examples, see the Hive QA comments on HIVE-9534 and HIVE-11752. Note that sometimes tests fail for reasons unrelated to the patch.
To prevent precommit testing, include the case-sensitive phrase NO PRECOMMIT TESTS in the Description section of the JIRA issue. You can remove it later as needed. For examples, see HIVE-5289, HIVE-7343, and HIVE-7375For patch updates, our convention is to number them like HIVE-1856.1.patch, HIVE-1856.2.patch, etc. And then click the "Submit Patch" button again when a new one is uploaded; this makes sure it gets back into the review queue.
Applying a Patch
To apply a patch that you either generated or found from JIRA, you can issue:
...