RDK Resources
[*RDK Preferred*]
Code Management Facility
RDK Forums
[RDK Conferences]
RDK Support
Archives
Papers & Presentations Archive
Developer clones component repository from Gerrit server https://code.rdkcentral.com/r/ into local work space
• 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.
Developer pushes the new change to Gerrit for review, i.e. to 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
Changeset needs to be reworked
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
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.
TODO> Provides the steps and snapshot of some of the pages
Sign-in to github with your own credentials.
Search for the Component.
Fork the component from github. Forking will create a copy(i.e, your own WORKSPACE) of an original component to work.
Click on the "Clone or download" button to get the clone url from github. Ensure your github username present in the url to start work with your own workspace.
Make the code changes, and commit the changes
$ git add . $ git status $ git commit -m "<JIRA_TICKET_ID> <COMMIT_DESCRIPTION>" $ git push
Once submitted the changes need to create pull request from github for review. Pull requests let you tell others about changes you've pushed to a branch in a repository on GitHub. Once a pull request is opened, you can discuss and review the potential changes with collaborators and add follow-up commits before your changes are merged into the base branch.
Pull Request page will be created.
Once you've created a pull request, you can push commits from your topic branch to add them to your existing pull request. These commits will appear in chronological order within your pull request and the changes will be visible in the "Files changed" tab.
Other contributors can review your proposed changes, add review comments, contribute to the pull request discussion, and even add commits to the pull request.