遵循以下最佳实践的项目将能够自愿的自我认证,并显示他们已经实现了核心基础设施计划(OpenSSF)徽章。 显示详细资料
[](https://www.bestpractices.dev/projects/6667)
<a href="https://www.bestpractices.dev/projects/6667"><img src="https://www.bestpractices.dev/projects/6667/badge"></a>
EmbeddedInfraLib is a set of C++ libraries and headers that provide heap-less, STL like, infrastructure for embedded software development.
Coding standard documented as part of the documentation: https://philips-software.github.io/amp-embedded-infra-lib/embedded_infrastructure_library/2.0.0/CodingStandard.html Repository includes a .clang-format file https://github.com/philips-software/amp-embedded-infra-lib/blob/modern-cmake/.clang-format and a CMake workflow to apply the formatting. The formatting is again checked as part of the GitHub actions https://github.com/philips-software/amp-embedded-infra-lib/blob/modern-cmake/.github/workflows/linting-formatting.yml and suggestions are added as annotations.
https://github.com/philips-software/amp-embedded-infra-lib/blob/modern-cmake/CODE_OF_CONDUCT.md
There is a team behind amp-embedded-infra-lib that has knowledge and authority to continue the project.
https://github.com/orgs/philips-software/teams/amp-embedded-infra-lib
Architecture and high-level design/decomposition is available as part of the documentation.
https://philips-software.github.io/amp-embedded-infra-lib/embedded_infrastructure_library/2.0.0/index.html
The documentation is part of the repository and where possible linted for inconsistencies, errors and spelling. It is then rendered to GitHub Pages.
All fixes to the documentation are done via PRs on the repository.
These badges are part of the readme: https://github.com/philips-software/amp-embedded-infra-lib.
Using GitHub Issues: https://github.com/philips-software/amp-embedded-infra-lib/issues.
The project's coding guide is documented here: https://philips-software.github.io/amp-embedded-infra-lib/embedded_infrastructure_library/2.0.0/CodingStandard.html.
clang-format is used to enforce the coding guide.
CMake is used to guarantee this. The fuzzing build is an example of externally injecting compilers and compiler flags to the build.
A RelWithDebInfo is available for all build targets.
CMake is used to guard dependencies; and while CMake can choose to generate recursive Makefiles it generates at maximum a three-level deep structure where each level has an intended purpose.
https://gitlab.kitware.com/cmake/community/-/wikis/FAQ#why-does-cmake-generate-recursive-makefiles
A dev container is used with all tools pre-installed.
GitHub Actions are used for reproduceable builds. All dependencies are pinned to hashes.
This requirement is described in the contributing guidelines: https://github.com/philips-software/amp-embedded-infra-lib/blob/modern-cmake/CONTRIBUTING.md.
The number of tests and coverage is trended, and coverage is gated by SonarCloud.
The settings for the warning tools are generally fairly strict.
Broken ciphers like MD5, DES and SHA-1 are disabled in our Mbed TLS configuration.
https://github.com/philips-software/amp-embedded-infra-lib/blob/modern-cmake/external/crypto/mbedtls/mbedtls_emil_config.h
SonarCloud checks for common vulnerabilities and bugs.
clusterfuzzlite is deployed to run continuous and per-Pull Request fuzzing. Sanitizers are included as part of this build.
后退