Page History

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

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

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

Note: In addition, the developer You may need to configure their your Git identity on the cloned repository. The email address that git your local Git uses should match the email address listed in gerritGerrit.

Example commands to run are as follows:

...

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.

Note: To 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

3. Developer works Work on the change, committing commit to local clone

Each commit constitutes a change in Gerrit and must be approved separately. It is recommended to squash several commits into one that represents a change to the project.

...

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.

4. Developer pushes Push the new change to Gerrit for review

...

5. Review notifications and addition of new reviewers

The Developer may request feedback by adding additional reviewers via the Gerrit web GUI or alternatively by specifying details on the command line when pushing changes to Gerrit. Component owners/reviewers/approvers, defined as specific groups in the external LDAP systemGerrit, will be added to the review by default.

Note: Optionally, additional reviewers can be added using ``%r=user@mail.com`` syntax during the push operation on the command line.

You may request additional feedback by specifically adding reviewers via the Gerrit web GUI. 

6. Scan 6. BlackDuck, copyright scanning and build on code submission

If applicable, 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.

7. Code review and scoring process

...

11. Change needs to be reworked

In order to submit a reworked change it is necessary If you need to rework a change, you need to push another commit that has with the same Change-ID as the original in the its commit message.
This is the mechanism Gerrit uses to associate or link the two items. The `--amend` option to git the Git commit command prevents a new Change-ID being generated by the commit-msg hook.

...

Note: Gerrit will specify this fetch URL via the web UI on the 'Download' link on the review page for the change in question, the developer you just pastes paste it into the command line.

...