Code Contribution Process

Step 1 : Developer to create RDKDEV/RDKBDEV tickets

Log in to JIRA https://jira.rdkcentral.com/jira/secure/Dashboard.jspa using rdkcentral credentials
Click on the Create button

RDK > Code Contribution Process > image2020-1-23_17-20-34.png

Step 2 : Developer clones component

Developer clones component repository from Gerrit server https://code.rdkcentral.com/r/ into local work space

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

Step 3 : Developer works on the change

• The Developer creates a topic branch in the local work area, makes the necessary changes and then squashes the commits prior to pushing for review.

git checkout -b <Branch Name>

Step 4 : Gerrit for review

Developer pushes the new change to Gerrit for review, i.e. to refs/for/master

git push origin HEAD:refs/for/master

• When interfacing with Gerrit you push to a virtual branch, /refs/for/<branch>, representing "code review before submission to branch".
• Gerrit will subsequently assign a unique URL for the change, to facilitate access and review via the web UI.

Step 5,6,7 :

Review notifications and addition of new reviewers.

The Developer may request feedback by adding additional reviewers via the Gerrit web GUI or command line.
Component owners/reviewers/approvers, defined as specific groups in the external LDAP system, will be added by default

Post Checkin process

Uses TDK for component validation

Run BlackDuck, copyright scanning and build on code submission.

• If applicable, BlackDuck, copyright scanning and build jobs will be triggered from 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.

Code review and scoring process

Reviewers can comment on and score a given change.
• The default set of rules for enabling a code change for submission requires a Code Review score of +2 and a +1 score on any mandatory Gerrit labels configured for the project.
• The result of the scoring process and validation rules is to enable the Submit action on the Gerrit Web UI and subsequent merge capability to the target branch.
+2 Value approval
‐2 Do not submit.
+1 Enables a submit
‐1 Block a submit

Step 8,9,10 : Changeset trigger and Verification

Changeset needs to be reworked

git fetch https://user@code.rdkcentral.com/r/component1 refs/changes/02/2/1 && git checkout FETCH_HEAD

where the numbering scheme for fetching the changes is as follows:
refs/changes/<last two digits of change number> <change number> <patch set number>

git commit --amend
git push origin HEAD:refs/for/master

A new patch set is now appended to the Gerrit review item, and this will go through the same review process as before.

Gerrit conflict resolution

git checkout -b topic_branch
git fetch https://user@code.rdkcentral.com/r/rdk_component_1 refs/changes/58/58/2 && git checkout FETCH_HEAD
git rebase origin/master

[Edit the conflicting file, cleaning up the <<<<, ==== >>> markers surrounding the conflicting lines]

git add <file>
git commit --amend
git push origin HEAD:refs/for/master

Rebase the local branch to the latest state of origin/master;
Resolve all conflicts;
Commit with the `--amend` option;
Push changes to Gerrit for review.

After this change a new patch set is created for the change.

Step 11 : JIRA ticket status update

After patch set trigger, Corresponding JIRA https://jira.rdkcentral.com/<ticket_number> will get reflected with the commit details.

RDK > Code Contribution Process > Screenshot (45).png

Step 12 : CMF build & test

Submit change

Only authorized users i.e. component owners and component approvers 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.

Abandon change.

A conscious decision is made to abandon the change based on the review outcome.
The component owner or an authorized user may abandon the change by clicking the "Abandon Change" button.
The abandoned changes are not removed from the Git repository and could be restored at a later stage.

Submitted, Merge Pending

The change depends on another change that is still in review.
In this case the change will be merged automatically once all its dependencies are submitted and merged

Once the changes got merged in CMF, ticket will gets automatically updated with those information.