Page History

1. Clone the component repository from the Gerrit server https://code.rdkcentral.com/r/ into a local workspace

Clone

$ git clone https://user@codecode.rdkcentral.com/r/component1

You can use your RDK password to authenticate Git operations over HTTPS. There is no need to generate a HTTP password within the Gerrit Web UI.

You may need to configure your Git identity on the cloned repository. The email address that your local Git uses should match the email address listed in Gerrit.

Example commands to run are as follows:

$ git config user.name "John Doe"
$ git config user.email "john.doe@example.org"

2. Set up the commit-msg hook to add Change-ID footer to commit messages

Clone with commit-msg hook (to add Change-ID footer to commit messages)

git clone https://code.rdkcentral.com/r/rdk/component1 && (cd component1 && gitdir=$(git rev-parse --git-dir); curl -o ${gitdir}/hooks/commit-msg https://code.rdkcentral.com/r/tools/hooks/commit-msg ; chmod +x ${gitdir}/hooks/commit-msg)

Note: The commit-msg hook is installed in the local Git repository and is a prerequisite for Gerrit to accept commits. The inclusion of the unique Change-ID in the commit message allows Gerrit to automatically associate a new version of a change back to its original review.

To download the commit-msg script from the Gerrit server to your local system use and make the hook file executable, do this:

$ cd <path_to_git_checkout>
$ curl -o .git/hooks/commit-msg https://code.rdkcentral.com/r/tools/hooks/commit-msg
$ chmod u+x .git/hooks/commit-msg

Note: You may need to configure your Git identity on the cloned repository. The email address that your local Git uses should match the email address listed in Gerrit.

Example commands to run are as follows:

$ git config user.name "John Doe"

$ git config user.email "john.doe@example.org"

23. Work on the change, commit to local clone

...

It is important to preserve the Change-Id line when editing and there should only be one "pick" entry at the end of this process. The end result is to submit one change to Gerrit.

43. Push the new change to Gerrit for review

...

• HEAD is a Git symbolic reference to the most recent commit on the current branch. When you change branches, HEAD is updated to refer to the new branch's latest commit.
• The refspec in the git push operation takes the form source:destination (source is the local ref being pushed, destination is the remote ref being updated).

54. Review notifications and addition of new reviewers

Component owners/reviewers/approvers, defined as specific groups in Gerrit, will be added to the review by default. You may request additional feedback by specifically adding reviewers via the Gerrit web GUI. 

65. Scan and build on code submission

BlackDuck, copyright scanning and build jobs will be triggered automatically from CMF Jenkins. The output of these jobs is integrated into the Gerrit voting process via custom labels and will reflect any 'red flag' in a file that has new code changes, whether introduced in the new change/patch-set or not. Scans will post any findings as comments in the Gerrit review. Build jobs also do that, but in addition will upload the build log to the corresponding JIRA ticket (if there is one) as an attachment.

76. Code review and scoring process

...

Note: Review input is generally referred to as labelling with a positive/negative score.

87. Submit change

Only authorised users, i.e. component owners, component approvers or admins, can submit the change allowing Gerrit to merge it to the target branch as soon as possible. A change can be submitted, having satisfied the approval conditions described earlier, by clicking the 'Submit Patch Set n' button within the Gerrit UI. When a change has been Submitted, it is automatically merged to the target branch by Gerrit.

98. Abandon change

Depending on the review outcome, it might be decided to abandon the change. The component owner or an authorised user may abandon the change by clicking the "Abandon Change" button. The abandoned changes are not removed from the Gerrit database and can be restored at a later stage.

109. Submitted, Merge Pending

If a change depends on another change that is still in review, it will enter this state. It will be merged automatically by Gerrit once all its dependencies are submitted and merged.

1110. Change needs to be reworked

...

Note: The 'change number' referenced above is different to underlying Git commit ID.
Note: Patch-sets are numbered (starting from 1) for each review, and incremented whenever a change is amended with another Git commit.
Note: FETCH_HEAD is a Git symbolic reference and shorthand for the head of the last branch fetched and is valid only immediately after the fetch operation.

1211. Gerrit merge failure as a result of a conflict

...