Tag: Continuous Integration

Posted on

Exploring Serverless CI/CD for Embedded Devices

Today we have a guest post from Kayode Alade. Kayode is an IoT Solutions Architect with a knack for making things work. He considers himself a perpetual learner, always enthusiastic about acquiring new knowledge, whether from an engineering perspective or a business standpoint. You can find Kayode on GitHub and LinkedIn. Embedded DevOps is changing …

Continue reading "Exploring Serverless CI/CD for Embedded Devices"

Embedded Artistry’s Continuous Integration Process

5 March 2020 by Phillip Johnston • Last updated 20 February 2025

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.

Table of Contents:

  1. An Overview of the CI Process
  2. Jenkins Rules
  3. Common Tooling Requirements
  4. Quality Enforcement Processes
  5. Related
  6. References

An Overview of the CI Process

The Embedded Artistry CI process is automatically launched when:

  1. A pull request is opened
  2. A new commit is pushed to a pull request
  3. 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 project
  • tools/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 files
  • make is required to use Makefile shims
  • cppcheck, clang-tidy, and clang-analyzer are used for static analysis
  • clang-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.

  1. Cross-compilation
  2. Unit Testing
  3. Static Analysis
  4. Code Formatting
  5. Code Coverage Analysis
  6. Open-Issue Scanning
  7. Documentation Linting

Each project will have some minor variation on the general theme. Some will differ slightly 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.

Tests are reported primarily through Jenkins. 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:

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.

References