Skip to content
Snippets Groups Projects
Commit 6735e1f0 authored by Suru Dissanaike's avatar Suru Dissanaike
Browse files

Update README.md

parent 9dda7cdc
No related branches found
No related tags found
No related merge requests found
......@@ -8,174 +8,3 @@ Shared pipelines for CI. Different types of testing that is done in the CI pipel
* Functional testing is defined as testing a slice of functionality in the system (may interact with dependencies) to verify that the code is doing the right things
The tests mentioned above should not be hardware dependent, it should be possible to execute the tests in a single Docker container.
## CI interface for make/cmake
It is fine to use either CMake or Make as long as the following commands are supported.
* make format **note not used by CI**
* make format-check **note not used by CI**
* make / make all
* make unit-test
* make functional-test
* make coverage
**Each make command must have the return code 0 to indicate pass or other value for a failer.**
[GNU Make naming conventions](https://www.gnu.org/prep/standards/html_node/Standard-Targets.html#Standard-Targets)
## iopsys CI workflow
```mermaid
graph LR;
ID1(Static Code Analysis)-->ID2(Building);
ID2(Building)-->ID3(Functional API testing)
ID3(Functional API testing) --> ID7(Dynamic Code Analysis);
ID2(Building)-->ID4(Unit Testing);
ID4(Unit Testing)-->ID5(Unit Test Coverage);
ID5(Unit Test Coverage)-->ID7(Dynamic Code Analysis);
ID2(Building)--> ID6(Integration/Functional testing);
ID6(Integration/Functional testing)-->ID7(Dynamic Code Analysis);
```
<details>
<summary>Prerequisites for different stages</summary>
### Prerequisite Static Code Analysis (SCA)
Basically none, the SCA can be done even if the code does not compile.
### Prerequisite Format Check
None
### Prerequisite Building
Libraries that are needed to build will be part of the Docker image.
### Prerequisite Unit Testing
None
### Prerequisite Unit Test Coverage
None
### Prerequisite Integration/Functional testing
Each module will most likely have a unique configuration, for example supervisord conf, json schema etc.
### Prerequisite Dynamic Code Analysis
TBD
</details>
## Static code analysis
* cppcheck (for static analysis)
* flawfinder (reports possible security weaknesses)
* cpd (for DRY checking)
TBD to use scan-build — Clang static analyzer.
### cppcheck
Cppcheck will perform static checks that may not be covered by the compiler itself.
<details>
<summary>More</summary>
These checks are static analysis checks that can be performed at a source code level, this means that the code does not need to compile.
Some of the checks that are supported include:
* Automatic variable checking
* Bounds checking for array overruns
* Classes checking (e.g. unused functions, variable initialisation and memory duplication)
* Usage of deprecated or superseded functions according to Open Group[3]
* Exception safety checking, for example usage of memory allocation and destructor checks
* Memory leaks, e.g. due to lost scope without deallocation
* Resource leaks, e.g. due to forgetting to close a file handle
* Invalid usage of Standard Template Library functions and idioms
* Miscellaneous stylistic and performance errors
[Source](https://en.wikipedia.org/wiki/Cppcheck)
</details>
### flawfinder
FlawFinder is a tool that scans your C/C++ source code for calls to typical vulnerable library functions.
<details>
<summary>More</summary>
Typical error types found:
* Calls to library functions creating buffer overflow vulnerabilities (gets, strcpy, sprintf, ...)
* Calls to library functions potentially vulnerable to string formatting attacks (sprintf, printf, ...)
* Potential race conditions in file handling.
[Source](https://dwheeler.com/flawfinder/)
</details>
### cpd
The **Copy/Paste Detector (CPD)** tool will find duplicate blocks of code.
<details>
<summary>More</summary>
If duplicates are found, analyse the code block and consider refactoring the code.
Advice on refactoring can be found [here] (https://refactoring.guru/smells/duplicate-code), the link describes in-depth strategies, use cases and explanations.
[Source](https://pmd.github.io/pmd/pmd_userdocs_cpd.html)
</details>
## Format Checking
CI interface:
* make format-check
## Building
CI interface:
* make
* make all
## Unit Testing
CI interface:
* make check
## Unit Test Coverage
CI interface:
* make run-code-coverage-metrics
## Integration/Functional testing/API testing
### API testing
API testing or API validation is done using the ubus-api-validation tool.
ubus-api-validator will validate your ubus method call using your schema.
The input to the validator is a json file or directory that contains the methods you want to validate.
Your schema must be placed in the following directory /usr/share/rpcd/schemas.
See following the [project](https://dev.iopsys.eu/Training/userspace-developer/ubus-demo) for a complete example which includes gitlab CI.
## Dynamic Code Analysis
* Code coverage
* Detect memory leaks
* Uninitialized accesses
* Concurrency issues
* Undefined behaviour situations
* Etc.
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment