|Table of Contents|
GitHub is a Git repository hosting service, but it adds many of its own features. While Git is a command line tool, GitHub provides a Web-based graphical interface.
GitHub Repositories on rdkcmf organisation
There are approximately 145 mirrors on the GitHub rdkcmf organisation, these are primarily mirrors of Gerrit opensourced repositories. Gerrit repository active branches are replicated to GitHub. Pull Requests are not supported on these repositories as indicated in the repository CONTRIBUTING.md files.
RDK Central GitHub Components & its Product Branches
A list of the public repositories include:
GitHub Pull Requests
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 review the potential changes with collaborators and add follow-up commits before your changes are merged into the base branch. Anyone with read permissions to a repository can create a pull request, but you must have write permissions to create a branch. If you want to create a new branch for your pull request and don't have write permissions to the repository, you can fork the repository first. Pull requests can only be opened between two branches that are different.
A ‘fork’ is a personal copy of another user's repository that lives on your GitHub account. Forks allow you to freely make changes to a project without affecting the original. A forked project also remains attached to the original, allowing you to submit a pull request to the original's author to update with your changes, ensuring you’re always working off a recent or up-to-date codebase.
GitHub Workflow Steps
- Create a Fork by simply clicking on the 'fork' button of the repository page on GitHub.
- Clone your Fork, the clone command creates a local git repository from your remote fork on GitHub.
- Modify the Code in your local clone, and commit the changes to your local clone using the git commit command.
- Push your Changes by invoking the git push command, from your workspace, to upload your changes to your remote fork on GitHub.
- Create a Pull Request by clicking the 'pull request' button on the GitHub page of your remote fork.
GitHub Protected Branches
Protected branches ensure that collaborators on your repository cannot make irrevocable changes to branches. Enabling protected branches also allows you to enable other optional checks and requirements, like required status checks and required reviews.
Required status checks ensure that all required CI tests are passing before collaborators can make changes to a protected branch. Status checks are based on external processes, such as continuous integration builds, code compliance scanning, which run for each push you make to a repository. You can see the pending, passing, or failing state of status checks next to individual commits in your pull request.
Contributor License Agreement (CLA)
The RDK CLA facilitates the acceptance and sharing of RDK contributions within the community.
Note - CLA assistant is provided by SAP as a free hosted offering under: https://cla-assistant.io/
CMF uses BlackDuck (Protex) to check incoming contributions for license compliance. BlackDuck is normally a very manual tool but a significant level of automation has been developed by the team to reduce manual intervention, but it still requires a human to oversee it.
OSS Engineer and interested parties are notified of scan failures (violations, pending identifications or reviews etc) via AWS Mailing list and Slack.
git-secrets is a tool created by AWS Labs that scans commits and commit messages and aims to prevent passwords and other sensitive information being committed to a git repository. The tool can also scan files or folders to look for secrets such as an AWS Access Key ID and AWS Secret Access Keys in a repository. git-secrets scans commits, commit messages, and merge commits to prevent adding secrets into your git repositories. If a commit, commit message, or any commit in merge history matches one of the configured prohibited regular expression patterns, then the commit is rejected.
Example of how to push the code changes
Step 1 : Fork the component from GitHub
Sign-in to github with your own credentials.
Fork the component from github. Forking will create a copy(i.e, your own WORKSPACE) of an original component to work.
Step 2 : Clone the Component
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.
Step 3 : Work on changes and Gerrit commands to push the changes
Make the code changes, and commit the changes
Step 4 : Create pull request for review the changes
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.
Step 5 : Working on review comments
Once you've created a pull request, you can push commits from your workspace 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.