|
| 1 | +# Contributing Guideline - Internal Repository |
| 2 | + |
| 3 | +## Branch Naming Convention |
| 4 | + |
| 5 | +Refer to the Developer Services Branching Policy and Git User [Guide](https://confluence.silabs.com/pages/viewpage.action?pageId=315870645). |
| 6 | + |
| 7 | +Use lowercase letters and hyphens (`-`) as delimiters. |
| 8 | +Google search treats a hyphen as a word separator, which helps improve the visibility of public repositories. |
| 9 | +We should structure our internal repository as if it were a public one. |
| 10 | + |
| 11 | +Branch name should be short and clear. If possible it can be the JIRA ticket name. |
| 12 | +Also it is recommended to include the JIRA ticket number. |
| 13 | +Example: |
| 14 | +``` |
| 15 | +IOT_DS-123-update-sdk-version |
| 16 | +``` |
| 17 | + |
| 18 | +## Commit Message Format |
| 19 | + |
| 20 | +We use [smart commits](https://support.atlassian.com/bitbucket-cloud/docs/use-smart-commits/) to sync GitHub commits with our JIRA server. |
| 21 | +This requires the JIRA ticket number in the commit message. |
| 22 | +The first line is the commit message, and the next lines provide the description. |
| 23 | +The commit message should be short and clear, and it must contain the JIRA ticket number. |
| 24 | +You can add more details in the description. |
| 25 | + |
| 26 | +**Command Line:** |
| 27 | +``` |
| 28 | +git commit -m "IOT_DS-1234 initial version of SDK 4.4.3 is committed" -m "Not final version. Several compiler warnings need to be addressed." |
| 29 | +``` |
| 30 | + |
| 31 | +**VS Code:** |
| 32 | +The first line is the commit message, and the next lines are the commit description. |
| 33 | + |
| 34 | +## Pull Request Guideline |
| 35 | + |
| 36 | +Refer to the general pull request [guideline](https://opensource.guide/how-to-contribute/#opening-a-pull-request) from GitHub. |
| 37 | + |
| 38 | +### As a Developer |
| 39 | + |
| 40 | +What to consider when raising a Pull Request: |
| 41 | + |
| 42 | +1. **Pull Request Naming** |
| 43 | + By default, GitHub uses the branch name as the pull request title. If the branch naming guideline was followed, no changes are needed here. |
| 44 | + |
| 45 | +2. **Check the Reviewer List** |
| 46 | + GitHub assigns reviewers based on the [CODEOWNERS](CODEOWNERS) file. |
| 47 | + Add more reviewers if needed. Do not remove reviewers from the PR. Ask the repository owner for updates to the code owners. |
| 48 | + |
| 49 | +3. **Evaluate the Action Workflow Results** |
| 50 | + The following workflows are included in every repository: |
| 51 | + - **[Coding Convention Check](workflows/00-Check-Code-Convention.yml)**: Analyzes the code formatting and fails if any rules are broken. |
| 52 | + - **[Firmware Build](workflows/02-Build-Firmware.yml)**: Builds the firmware inside the [Dockerfile](../Dockerfile). |
| 53 | + - **[Secret Scanner](workflows/04-TruffleHog-Security-Scan.yml)**: Runs the TruffleHog security scanner to look for API keys and committed secrets. |
| 54 | + - **[SonarQube Analysis](workflows/zz-sonarqube-analysis.yml)**: Runs SonarQube analysis on the project. Refer to the related [Confluence page](https://confluence.silabs.com/display/IoTApps/SQA+-+SonarQube+howTo). |
| 55 | + |
| 56 | +### As a Reviewer |
| 57 | + |
| 58 | +What to consider when reviewing a Pull Request: |
| 59 | + |
| 60 | +- All builds must pass successfully. |
| 61 | +- The code must follow the Silicon Labs [coding guidelines](https://github.com/SiliconLabsSoftware/agreements-and-guidelines/blob/main/coding_standard.md). |
| 62 | +- Write clear comments. Describe the issue and explain why you disagree (e.g., mistakes, errors, violations of conventions, performance risks, security issues, etc.). |
| 63 | +- If any comments must be addressed mandatorily, mark the pull request as “Draft.” |
0 commit comments