Continue reading "Exploring Serverless CI/CD for Embedded Devices"
Embedded Artistry’s Continuous Integration Process
Most of our open source projects utilize continuous integration (CI) using Embedded Artistry’s Jenkins build server. Developers who are interested in contributing to Embedded Artistry open source software projects will benefit from understanding our CI process at a basic level.
If you think you need access to the build server, please contact Phillip.
An Overview of the CI Process
The Embedded Artistry CI process is automatically launched when:
- A pull request is opened
- A new commit is pushed to a pull request
- A new commit is pushed to master
The build server will report passing or failing status back to GitHub. Most projects utilize these status checks as a gate for merging.
The image below provides a high-level overview of the CI process on the Embedded Artistry build server.
In addition, we have a nightly versioned build for most projects. This build runs once a day, but only when new commits have been added to master
. The same quality control checks are run. The main difference is that successful builds are tagged with a new version number. Some projects will also archive generated build artifacts (e.g., compiled libraries, documentation) for distribution.
Jenkins Rules
All projects store their CI project rules in a standard location within the project repository:
tools/CI.jenkinsfile
represents the CI build for the projecttools/Jenkinsfile
represents the nightly build for the project
You can see exactly what is happening for a given project’s CI process using these files. To see an example, we recommend libc:
If either of these files is missing, that process will not be run for the project
Common Tooling Requirements
Most Embedded Artistry projects use the following tools. We recommend installing them on your local system if you will be participating in Embedded Artistry projects.
- A compiler should be installed in order to build the project (gcc + clang have been tested)
- Meson is the primary build system
- Doxygen for documentation generation
git-lfs
is used to store binary filesmake
is required to use Makefile shimscppcheck
,clang-tidy
, andclang-analyzer
are used for static analysisclang-format
is used to automate and enforce our source code formatting requirements- lizard is used for complexity analysis
Quality Enforcement Processes
We strive to include the following categories of quality enforcement processes in our automated CI pipeline. The tools we use for each process are described below.
Each project will have some minor variation on the general theme. Some will differ in the processes or tools that are used. We are always trying to unify the process for each of our projects.
Cross-compilation
Many of our projects are intended for use on embedded systems. These projects will also run a cross-compilation step to ensure that there are no problems when building for another platform.
At this time, we primarily use gnu-arm-none-eabi
for our cross-compilation checks.
Unit Testing
If unit tests are included in the project, they will be run. Both successful and failing results will be archived on the build server.
Many of our projects will also upload test results and code annotations to the GitHub pull request using Report.CI. This allows you to view test failures within the GitHub interface.
Static Analysis
For many of our projects, a combination of the following static analysis tools are used:
- Cppcheck
- Clang Tidy
- Clang Analyzer
- Lizard, which monitors for complex functions that should be refactored
Mature projects will automatically fail builds that introduce new static analysis warnings.
Code Formatting
The build server will reject pull requests which do not meet our formatting requirements.
You can auto-format your code to match the style guidelines by issuing the following command:
make format
Formatting is enforced by the Jenkins build server which runs continuous integration for this project. Your Pull Request will not be accepted if the formatting check fails. If you cannot install clang-format
on your machine for some reason, please let us know and we can help you with formatting updates.
For more on our code formatting process, see the following articles:
- Creating and Enforcing a Code Formatting Standard with clang-format
- A Strategy for Enforcing Formatting with Your Build Server
Code Coverage Analysis
For some projects, test coverage is monitored using gcov
.
Open-Issue Scanning
Our build server monitors comments which include phrases such as TODO
, FIXME
, and WIP
. Your pull request will be rejected if you submit partial work.
Documentation Linting
For some projects, documentation is linted using tools vale
. Warning and error limits are enforced on a per-project basis.