diff --git a/README.md b/README.md index 8c749ac3c40315ee2099ff43ba3d1f2b978abaaa..5324e66004787008180672f5c67125846dfa34f8 100644 --- a/README.md +++ b/README.md @@ -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.