RDK Resources
[*RDK Preferred*]
Code Management Facility
RDK Forums
[RDK Conferences]
RDK Support
Archives
Papers & Presentations Archive
Table of Contents | ||
---|---|---|
|
...
Gliffy Diagram | ||||||
---|---|---|---|---|---|---|
|
Developer clones component repository from Gerrit server https://code.rdkcentral.com/r/ into local work space
Panel |
---|
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.
Panel |
---|
git checkout -b <Branch Name> |
Developer pushes the new change to Gerrit for review, i.e. to refs/for/master
Panel |
---|
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.
...
Deployment ready Product Branch has been created for RDK components that the community will push changes to review & It is with higher standards of test qualification
draw.io Diagram | ||||||
---|---|---|---|---|---|---|
|
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.
Product branch is a deployment ready branch is created for RDK components that the community will push changes to review.
Refer to Product Branch for the Components hosted in CMF Gerrit (https://code.rdkcentral.com)
Refer to RDK Central GitHub Components & its Branches hosted in https://github.com/rdkcentral/
Monthly Sprint Branch (rdk-dev-yymm) is a new CMF integration branch, created monthly and baseline off Product Branch. This branch will be hosted per repository in conjunction with Product branch with the goal of incorporating community changes at the earliest juncture.
Once community changes is approved, will be cherry-picked to Monthly Sprint branch (rdk-dev-yymm) and will thus be available prior to the completion of down-streaming to Regression Branch / round-trip process.
Regression branch is the branch used for validation of the contributions. Approved contributions will be down-streamed to Regression Branch for pre-deployment validation using their test process.
Down streamed Community changes, successfully merged to Regression branch, after pre-deployment test validation, the code changes will be cherry-picked to Product Branch.
Code Submission Process - RDK Central Gerrit
Code Submission Process - RDK Central GitHub
Post Checkin process
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
Submit change
Abandon change.
...
Panel |
---|
git fetch https://user@code.rdkcentral.com/r/component1 refs/changes/02/2/1 && git checkout FETCH_HEAD |
...
Panel |
---|
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
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]
...
After this change a new patch set is created for the change.