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 |
• 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> |
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.
Review notifications and addition of new reviewers.
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
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 |
A new patch set is now appended to the Gerrit review item, and this will go through the same review process as before.
git checkout -b topic_branch [Edit the conflicting file, cleaning up the <<<<, ==== >>> markers surrounding the conflicting lines]
|
After this change a new patch set is created for the change.
Submit change
Abandon change.
Submitted, Merge Pending
Once the changes got merged in CMF, ticket will gets automatically updated with those information.